Uzebox Live Back in action

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
CompMan
Posts: 91
Joined: Mon Aug 25, 2008 3:48 am
Location: Kent, WA

Uzebox Live Back in action

Post by CompMan »

It's been a long time since I've been able to be online. My job and school have been getting in the way. I see a lot has changed including an awesome emulator!!!

Now down to business. I am about to begin work on the Uzebox Ethernet connection again. I have been having several discussions with my fellow programmers about how to implement a live system. Before I continue with too much work I would like some answers. Does anyone still want Uzebox Live to be a reality? Do you have any ideas about how it should be implemented?

CompMan
User avatar
pragma
Posts: 175
Joined: Sat Sep 20, 2008 2:16 am
Location: Washington, DC

Re: Uzebox Live Back in action

Post by pragma »

CompMan wrote:Does anyone still want Uzebox Live to be a reality?
OOC, what features from XBOX live should be borrowed here - application distribution, multiplayer, chat, etc? :D

Also, where will the TCP/IP stack live? Is there a suitable chip that will keep us from implementing all the networking specifics on the main uzebox CPU? If so, then I say this is an excellent idea. Otherwise, we (the community here) might be better served by supporting any SD bootloader efforts already underway; granted that doesn't solve any multiplayer problems, but it does tidy up the game distribution problem that Uzebox Live could solve.
User avatar
codecrank
Posts: 66
Joined: Sun Nov 16, 2008 10:13 pm
Location: Denver, Co

Re: Uzebox Live Back in action

Post by codecrank »

That would be sweet, I could retrofit Dr Mario or Megatris :)

If you need hosting for the central server app, pm me.
havok1919
Posts: 474
Joined: Thu Aug 28, 2008 9:44 pm
Location: Vancouver, WA
Contact:

Re: Uzebox Live Back in action

Post by havok1919 »

CompMan wrote:Now down to business. I am about to begin work on the Uzebox Ethernet connection again. I have been having several discussions with my fellow programmers about how to implement a live system. Before I continue with too much work I would like some answers. Does anyone still want Uzebox Live to be a reality? Do you have any ideas about how it should be implemented?
We should probably share hardware notes at some point... I'm sticking the Microchip ENC28J60 down on the 'experimenter' board. (Right now I'm using the same SPI bus as the SD Card, then PORD.4 for the /CS and PORTD.2 (/INT0) for the /INT output from the '28J60.) Would be nice to stay hardware compatible if possible!

-Clay
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox Live Back in action

Post by uze6666 »

Would be nice to stay hardware compatible if possible!
Essential!

Uze
CompMan
Posts: 91
Joined: Mon Aug 25, 2008 3:48 am
Location: Kent, WA

Re: Uzebox Live Back in action

Post by CompMan »

pragma wrote:
CompMan wrote:Does anyone still want Uzebox Live to be a reality?
OOC, what features from XBOX live should be borrowed here - application distribution, multiplayer, chat, etc? :D

Also, where will the TCP/IP stack live? Is there a suitable chip that will keep us from implementing all the networking specifics on the main uzebox CPU? If so, then I say this is an excellent idea. Otherwise, we (the community here) might be better served by supporting any SD bootloader efforts already underway; granted that doesn't solve any multiplayer problems, but it does tidy up the game distribution problem that Uzebox Live could solve.
It would take some of the uzebox CPU because of how we were planning on doing it. When we first started we designed the hardware interface using the Microchip ENC28J60. But if we must we may be able to make a few modifications.

CompMan
CompMan
Posts: 91
Joined: Mon Aug 25, 2008 3:48 am
Location: Kent, WA

Re: Uzebox Live Back in action

Post by CompMan »

havok1919 wrote:
CompMan wrote:Now down to business. I am about to begin work on the Uzebox Ethernet connection again. I have been having several discussions with my fellow programmers about how to implement a live system. Before I continue with too much work I would like some answers. Does anyone still want Uzebox Live to be a reality? Do you have any ideas about how it should be implemented?
We should probably share hardware notes at some point... I'm sticking the Microchip ENC28J60 down on the 'experimenter' board. (Right now I'm using the same SPI bus as the SD Card, then PORD.4 for the /CS and PORTD.2 (/INT0) for the /INT output from the '28J60.) Would be nice to stay hardware compatible if possible!

-Clay
We should share notes. The hardware must be compatible! Sounds like you have a lot on your 'experimenter' board. Do you have a schematic showing the Ethernet connections? Or a schematic of your 'experimenter' board?

Compman
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox Live Back in action

Post by uze6666 »

OOC, what features from XBOX live should be borrowed here - application distribution, multiplayer, chat, etc?
Application distribution is here, so remains multiplayer and -- good idea -- chat. Now that I've implement the SNES mouse...what about web browsing?! ;) Would work only if we have some sort of proxy server that converts and simplifies content for the Uzebox...

Uze
havok1919
Posts: 474
Joined: Thu Aug 28, 2008 9:44 pm
Location: Vancouver, WA
Contact:

Re: Uzebox Live Back in action

Post by havok1919 »

CompMan wrote:We should share notes. The hardware must be compatible! Sounds like you have a lot on your 'experimenter' board. Do you have a schematic showing the Ethernet connections? Or a schematic of your 'experimenter' board?
Right now it's relatively sparse in electronic format-- mostly sketched out on various pieces of paper, but I'll tidy up what I have in the next day or two. At the moment I have:

AVCore module as the "core" (MCU+video+audio+uSD) +

(preliminary)
SPI:
PORTD.7 = chip select for uSD on AVCore
PORTD.6 = chip select for standard SD slot on experimenter board (I'm not sure if that's useful or not-- the idea was you could have an "app" on the uSD and still have removeable media on the full-sized SD if you wanted) Alternate plan would just be standard SD sharing the uSD chip select so you could use either socket depending on what you prefer/need)
PORTD.5 = chip select to 'helper' MCU (ATTiny2313)-- provides PS/2 keyboard and Mouse ports
PORTD.4 = chip select to ENC28J60 (plus /INT connecting to PORTD.2)

SERIAL (Hardware UART on PORTD.0,1) :
DB9 serial with MAX-232 type transciever (or, by jumper selection...)
MIDI IN/OUT (or, by jumper selection...)
USB to serial by FTDI FT232BM

CONTROLLERS (PORTA):
Two standard SNES controller ports, headers to use any/all PORTA pins for external I/O (handy since they have the the ADC)
Potentiometer on PORTA.7 (with disable jumper) to use as 'volume control' (or other 'analog' input) by reading value with ADC

VIDEO (PORTC+support signals):
Standard Svideo and composite video (maybe component video-- if that doesn't make the PCB too big with the extra three RCA jacks!)
Header for RGB+CSYNC

AUDIO:
"dual mono" RCA outputs with active audio filter (vs. R/C filter on AVCore-- for people that want to use it as a synth with better sound quality)

One thing I might need to change-- on the original AVCore I had labeled PORTD.4 as "SPI_CS2" and PORTD.3 as "SPI_CS3". But to show that they're just GPIO I used them as the 'power' and 'LED' on the Gamer Baseboard figuring that the Gamer Baseboard and Experimenter baseboard wouldn't really run the same apps... In hindsight I probably should have just used PORTB.1 and PORTB.2. Sooo, since I can't un-pee in that pool now, maybe just put the Ethernet chip select and the keyboard/mouse chip select on PB1 and PB2 instead and that way we maintain our 'default' LED and button input across both platforms and software runs on each?

The only other thing I'm considering is to just stick down a ~$1 CPLD on the SPI bus and use the remaining GPIO on the AVR as a chip select and make a little SPI<->parallel shifter. (Shift bits in and out and simultaneously latch the new parallel 'output' values onto the pins on the rising edge of the chip select.) Otherwise it's a little low on I/O. An alternative to that is to use something like a ATMega48 for the keyboard/mouse controller and just make all the leftover I/O on the Mega48 available as GPIO/ADC's. I kinda like that better for only a small cost delta.

-Clay
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox Live Back in action

Post by uze6666 »

:shock: Wow, that's gonna be a heck of a board...everything and the kitchen sink! :D

As far as all those pin allocation you mentionned, wouldn't it be better to strive for compatibility with the existing design? Correct me if I'm wrong, but PORTD.6 is actually used for the microSD chip select no? Why move it to PORTD.7, which is btw the sound PWM pin. I'd like to ear what others have to say, but I don't see lots of application using 2 SD cards on a 64K device ;) ! For the dual audio channel what pin(s) did you think of? It would have required PORTD.6, which is OC2B, the second compare unit of timer1. As for the addition of more chips (specially CPLDs or another MCU), I'm unsure. It goes a bit against the KISS philosophy of the project...but, at the same time, it's an experimenter board after all! A SuperUzebox (tm). :)

I think my concern is that some great ('uzebox standard') stuff works on one board, but not in the other. Sure, if folks stick to the kernel/api we can have some slack to move things around a bit with the help of the new EEPROM config stuff. In the other hand, that makes the kernel more complex (and more heavy too).

Anyway, awesome stuff so far! :)

Uze
Post Reply