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
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Uzebox 128+

Post by Jubatian »

D3thAdd3r wrote: Fri Feb 16, 2018 6:56 amThe video mode is trivial, and at 6 cycles per pixel for 256x200, there is 2 free cycles every 7 out of 8 pixels.
256 pixels horizontally requires 5.5 cycles per pixel (extended resolution Mode 3), 6 cycles per pixel is the normal Mode 3 (240 pixels, usually slightly off-screen on the left or right).
D3thAdd3r wrote: Fri Feb 16, 2018 6:56 am... the OS must be able to follow cluster chains ... 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.
FAT16 or FAT32 has the required features, if you do an own filesystem, it wouldn't be much simpler. To make it simpler to code for yourself, you might use a fixed FAT filesystem image (so you can work with a fixed cluster size and known other properties instead of having to create a generic FAT driver), then you could still mount it on a PC and transfer files to it.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzebox 128+

Post by D3thAdd3r »

Ah yes should have said there is 10 free clock per 8 pixels, which fits the alternating 6/5 cycles per pixel. Higher horizontal resolution could be possible, but it seems to me the ram consumption is already quite high at ~6K, which will be a challenge to redraw at a good rate anyway.

Perhaps it is best just to go with FAT style. I never extensively used FatFS as PFF usually did what I needed, but my understanding of it is that it can support multiple open files simultaneously, removing files, etc. I guess I should explore further before starting to roll my own, as a good deal of the work is probably already done there.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzebox 128+

Post by D3thAdd3r »

Since I still have not got a board fabricated yet, I am slightly tickled by the idea of a second CPU. Compatibility is number 1 objective, but a second CPU on SPI should not cause issues as it just wont be used. It doesn't seem there is much else that could be done, while maintaining compatibility (and price is no object, as there is way more time than money into making these either way).

A second CPU could overlay high quality sound at the PCB trace level, and do anything where computational requirements are greater than bandwidth (SPI being maxed at 1 byte per 18 clocks). Emulation might actually fit this well, as there is probably 20:1 cycles to emulate things low level. Not sure emulation is really the target here though, just random musing, as I do.
Post Reply