Uzebox 128+

Topics regarding the Uzebox hardware/AVCore/BaseBoard (i.e: PCB, resistors, connectors, part list, schematics, hardware issues, etc.) should go here.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox 128+

Post by uze6666 »

With Alec having the keyboard+mouse situation more or less handled there is no more stall here.
Prototype pcbs are in the mail from China. As soon as I get them, I'll send you some and resume the software dev for the driver.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzebox 128+

Post by D3thAdd3r »

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

Re: Uzebox 128+

Post by uze6666 »

uzebox_ps2_pcb.jpg
uzebox_ps2_pcb.jpg (117.72 KiB) Viewed 11573 times
They took forever to arrive, but at last they are in. I will assemble one tomorrow and hopefully I didn't make a stupid mistake. :)
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox 128+

Post by uze6666 »

Well, I built it and...it doesn't work. Obviously. :roll:

I use the UART port to debug so I know the code works on the atmega168 and mouse/keyboard initializes, but there's seem to be a problem with the bus to the Uzebox. Will have to get out the scope and trace what is going on. To be continued!
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzebox 128+

Post by D3thAdd3r »

You always figure these things out, no doubt on that. Is the BOM stable at this point or do you see any changes coming? I'd like to get the parts now so I am ready when your newest invention arrives :)
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox 128+

Post by uze6666 »

The BOM should be final. But until, I find out the root cause of the current problem, I can't say for sure I didn't miss a thing.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzebox 128+

Post by D3thAdd3r »

I'm reasonably far along on a TQFP all surface mount PCB design, inspired by Clay Cowgill's AVCore. It will be larger than that, since the ESP8266 itself is half the size of an AVCore and I am building the headphone amp into the PCB also. All the external ports will be on a daughterboard for easier case mounting(I think this setup would be good for a portable too).

One big thing I need to figure out is the smallest/simplest way to make a Sony CXA2075 work. I have found the RGB port on the Uzebox cannot actually work, if you have the AD725 soldered in. It can probably be done with an analog switch, but then even that would require either more circuitry for detection, or manual user switching. CXA2075 will output composite, s-video, and RGB simultaneously. RGB is a critical goal for me. Apparently it has higher video quality but also draws more power.

I found and ordered these nice things:
mini-din-9-adapter.jpg
mini-din-9-adapter.jpg (11.65 KiB) Viewed 11396 times
These are for 9 pin min-din connectors(apparently made for ATI Radeon X800 series graphics cards), and each unit will come with one. So there is only 1 video planned, which is the 9 pin these connect to. There would be options to make a smaller dedicated single format cable of course.

These are the power supplies I decided on, they are visually nice and should be able to run the laser engraver to put "Uzebox 128" on there. I'm ordering a couple different plugs for US,EU,AU since if I ever get these done, the people I would give demos to are scattered across the power types/world. They output 12v and handle 100-240 volts 50/60hz:
s-l500.jpg
s-l500.jpg (6.01 KiB) Viewed 11393 times
That's all for now, I will hopefully get this PCB done and can show a pic. It wont work the first time of course.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzebox 128+

Post by D3thAdd3r »

Have not talked about this in a long time, but a little progress has happened. I am interested again. The new name is KUzebox 1284, and the main change is now targetting the 1284 via overvolting and different resistors. It will be backwards compatible for games, and Jubatian has indicated he might update his bootloader for the 1284. Will definitely want to ship these with the new bootloader, as it has some flashing features I would like to take advantage of.

No special games are planned as I mean to continue all game developments for standard Uzebox, but I am(perhaps foolishly)developing an OS for this. The OS wont run on 644 because there simply is not enough ram. It uses the extra ram for a frame buffer, and the GUI desktop should be somewhere in the region of 256x200 monochrome. User programs will be interpretted leaning heavily on SPI ram, so games are not the focus(basically have to flash it, then flash OS back), and it wont be fast. Long ways off, just have to talk positively about it so I actually continue on with it!
User avatar
ry755
Posts: 226
Joined: Mon May 22, 2017 6:01 am

Re: Uzebox 128+

Post by ry755 »

D3thAdd3r wrote: Tue Feb 13, 2018 10:31 pm Have not talked about this in a long time, but a little progress has happened. I am interested again. The new name is KUzebox 1284, and the main change is now targetting the 1284 via overvolting and different resistors. It will be backwards compatible for games, and Jubatian has indicated he might update his bootloader for the 1284. Will definitely want to ship these with the new bootloader, as it has some flashing features I would like to take advantage of.

No special games are planned as I mean to continue all game developments for standard Uzebox, but I am(perhaps foolishly)developing an OS for this. The OS wont run on 644 because there simply is not enough ram. It uses the extra ram for a frame buffer, and the GUI desktop should be somewhere in the region of 256x200 monochrome. User programs will be interpretted leaning heavily on SPI ram, so games are not the focus(basically have to flash it, then flash OS back), and it wont be fast. Long ways off, just have to talk positively about it so I actually continue on with it!
A simple OS sounds cool! I would definitely upgrade to a 1284 for something like that.

For the GUI design, would something like the original Macintosh desktop work?
Image
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzebox 128+

Post by D3thAdd3r »

Yes, precisely that!

GEMS and others are all cool, but it doesn't get more classic than the old Macintosh OS for me. The video mode is trivial, and at 6 cycles per pixel for 256x200, there is 2 free cycles every 7 out of 8 pixels. This could be used for some state machine that can perform block transfers. HSYNC would use the vsync mixer, so there are cycles there that can be used.

The user programs will have to be interpreted, and I am thinking something like an existing 6502 or 6800 core, or something of a higher level asm which might help performance(Uze8 would be an example that such a thing can actually run). The nice thing about asm, is that you could develop right on the machine. A custom asm might be able to give some of the main parts of C that are attractive, without all the impossible overhead of interpreting it. There could me multiple interpreter cores also, since there is 128K of flash that is only useful for core OS stuff.

I think 4 "threads", where a virtual CPU state is stored per, and simply a set amount of instructions are processed before a context switch. Each thread getting something like 2K of fast ram(no need for vram, as it is all shared), and some simple cooperative system to divide up the SPI ram. The programs would have to cooperate, as it is much simpler to not have to do any form of memory management/protection on the OS. No virtual memory, etc. Each thread would have some basic structures in the OS like a window, the layer it is on as opposed to others, and IO designations. Since it is interpreted, the OS would need a basic graphics library to perform drawing. The OS handles where the windows are, and any time one of these becomes a "dirty rectangle", the OS would describe a rectangle that the program needs to redraw(whatever another window has ran over). For sound, there would have to be a big work buffer before the vsync mixer buffer, so that there is some time to get it all together before it is output.

File system seems like the hardest part. FatFS might be able to work with individual files on the SD card. Otherwise I'd like to try and make an ultra simple file system that is contained in a single file on the SD, which encompasses the maximum possible storage for the entire system(say 256MB). It would not be easy to do this though, even for a "simple file system". It seems like the bare minimum would be the ability for user programs to seek to an offset in a file(which means the OS must be able to follow cluster chains), read a sector, and write a sector. The nasty part is when file sizes change, which is a pretty important ability for something that is supposed to be an OS I would guess.
Post Reply