Uzem modifications

The Uzebox now have a fully functional emulator! Download and discuss it here.
User avatar
uze6666
Site Admin
Posts: 4487
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzem modifications

Post by uze6666 » Wed Feb 04, 2015 7:35 pm

CunningFellow wrote:What about the idea of using the SPI RAM is DQI mode to direct pump out a 4BPP bitmap ?

Will there be any consideration be given to that idea before an official spec/schematic is decided upon ?
I'm not too fond of inserting chips in the video DAC path for a couple reasons. That need a redesign of the circuit and PCB and there's no way to make it backward compatible with other Uzebox implementations (i.e. not pluggable via the EXT port). Part of the bus will have to be bidirectionnal and may need some tri-state buffers too. Video code in Uzem is not trivial and would require lots of work. Or perhaps I don't understand you idea?

That said, I guess SQI could be used with the upper nibble of PORTA. I initially rejected the idea because 5 pins minimum would be required (4 data, 1 CS) and we would have to bit-bang the data and eat precious cycle vs. using the '644 SPI so you can do stuff in between transfers.

But its feasible to use both the SPI and PORTA upper nibble. When doing transfers in SPI mode (which you need anyway to initialize) that would use the 644 SPI. IN SQI, the 644 SPI clock line would be used with PORTA for the data lines. There's still bit-bang to do and all cycles are taken to toggle the lines and access the port. With it, a byte could be transfered in about 7-10 cycles. It's about twice as fast than regular SPI but not sure if it's worth the added complexity and free pins. Feel free to comment.

CunningFellow
Posts: 1196
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzem modifications

Post by CunningFellow » Wed Feb 04, 2015 11:17 pm

You understood what I meant. I was advocating splicing the DAC lines and putting in. Quad 2"1 multiplexer.

I had just thought if you were going to split the ecosystem and drive a wedge between the haves and the have nots you might as well try to gain AS MUCH extra functionality as possible from the extension.

If its just extra 2nd tier slow memory you are after, you can do that with API extension to read/write SD.

Yes, the SD is slower for random access that SPI ram. But they are both too slow on SPI mode to extend video RAM.

Feel free to ignore me though as I probably wont use the SPI ram. A bit because it punishes early adopters, but mainly because I find most of the fun in doing amazing things with little resources. half a meg of ram on tap makes the uzebox seem less like doing cool stuff with a 6502 to be more like doing "also ran" stuff on a 16 bit era machine.

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

Re: Uzem modifications

Post by uze6666 » Thu Feb 05, 2015 12:08 am

I totally agree with you regarding the limited resources challenge. It's part of the charm and simplicity is elegant. My heart is divided on the subject and I never liked the idea of fragmenting the user base. It is true that it doesn't bring much since it is so slow, thought it could be interesting for those just wanting to experiment. Anyway, I won't be modifying the reference design anytime soon. The PCB would need too much rework and I don't want to get into it now. So I went with the daughterboard approach for now (more in an upcoming post).

User avatar
nicksen782
Posts: 677
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Uzem modifications

Post by nicksen782 » Sun Feb 08, 2015 2:32 am

Since we are talking about changes to Uzem may I suggest Emscripten compatible builds? I've been researching and experimenting and it seems totally possible to convert an SDL app to a web application.

User avatar
D3thAdd3r
Posts: 2424
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzem modifications

Post by D3thAdd3r » Thu Feb 12, 2015 10:00 pm

nicksen782 wrote:Since we are talking about changes to Uzem may I suggest Emscripten compatible builds? I've been researching and experimenting and it seems totally possible to convert an SDL app to a web application.
I agree it would be pretty awesome. I would be worried that it is a ton of work and the resulting program would be too slow. Uzem code is, as Alec aptly put it "not for the feint of heart". I've read a bit that they were someone getting some applications to run 50% or better of the native compiled version. That is pretty amazing, but my 2.x ghz multi-core laptop I use for a lot of development barely runs Uzem full speed the way it is. It's difficult to get anyone interested/motivated to work on Uzem at all and it definitely needs a good cleanup. Like a lot of good ideas it can only be fully appreciated when someone just pioneers and makes it happen.

uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: Uzem modifications

Post by uberlinuxguy » Fri Feb 13, 2015 3:49 am

D3thAdd3r wrote: ... Uzem code is, as Alec aptly put it "not for the feint of heart" ... It's difficult to get anyone interested/motivated to work on Uzem at all and it definitely needs a good cleanup...
It's actually not that bad once you get into and figure out how the state machines in it work. It's actually a pretty cool setup. I've had great fun getting to know it and work on the SPI/SD/SPI_RAM code in the emulator. It's not quite working yet, but now that I seem to have a working program that uses the SPI_RAM module correctly, and some indications on where I might have broke the SD code in the emulator, I might play with it a bit more. It's going to be a little difficult for me to find time soon, as work is about to get crazy, but I think I might enjoy it enough to use it as a decompression task after a long day of work. That's not really masochistic is it? :D

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

Re: Uzem modifications

Post by uze6666 » Fri Feb 13, 2015 4:27 am

uberlinuxguy wrote:
D3thAdd3r wrote: ... Uzem code is, as Alec aptly put it "not for the feint of heart" ... It's difficult to get anyone interested/motivated to work on Uzem at all and it definitely needs a good cleanup...
It's actually not that bad once you get into and figure out how the state machines in it work. It's actually a pretty cool setup. I've had great fun getting to know it and work on the SPI/SD/SPI_RAM code in the emulator. It's not quite working yet, but now that I seem to have a working program that uses the SPI_RAM module correctly, and some indications on where I might have broke the SD code in the emulator, I might play with it a bit more. It's going to be a little difficult for me to find time soon, as work is about to get crazy, but I think I might enjoy it enough to use it as a decompression task after a long day of work. That's not really masochistic is it? :D
It would be important that your code is written to supports only one chip by default on the pins we agreed. How multiple chips can be supported transparently, let me know of the approach you think is best.

uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: Uzem modifications

Post by uberlinuxguy » Fri Feb 13, 2015 4:44 pm

uze6666 wrote:It would be important that your code is written to supports only one chip by default on the pins we agreed. How multiple chips can be supported transparently, let me know of the approach you think is best.
Basically, I am planning on supporting it via defines in an spi_ram.h file. Those defines set the bit mask for the pin in the PORTA/DDRA registers. Example:

Code: Select all

#define BANK0 0b00010000  
#define BANK1 0b00100000
#define BANK2 0b01000000
#define BANK3 0b10000000
You will be able to pass one of these values to the subsystem (in a way I haven't solidified yet) and I might see if I can set it up so that the default one is BANK0 if the user doesn't specify one. I'm still working out how that code will all look as what I have thrown together was mostly just to test how the data transfer will actually work. I have to take the time to think about the best way to handle the API next. I wrote all of the SPI RAM code in assembly, so I might rework it a bit or add some C abstraction over top of it. I know size is a concern so I want to keep it small and simple.

uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: Uzem modifications

Post by uberlinuxguy » Wed Feb 25, 2015 8:42 pm

Ok, I feel as though I must be insane, but here is what I am seeing.

I get nothing but errors when I try my modifications to the emulator, pretty much when trying to do any FAT reads to the SD card from any rom that does that sort of thing.

So being very confused, I grabbed a vanilla copy of uzem and compiled it. Ran the same tests and much to my surprise, things were the same.

I have 2 questions:

1) What OS has uzem been tested to this extent on?
2) Does anyone else see the same failures with games like Alter Ego, Tornado2k, uze8, etc)
3) How is the uzem.exe binary on the google site compiled?

Games tested with stock that fail:
Alter Ego
Tornado2k
uze8
Uzemario
uzetherm


What makes this more interesting is that the uzem.exe from the google site works fine. I am now stumped. I am beginning to wonder if it is how I am compiling the uzem.exe. I am using mingw in eclipse and the default Makefile that comes with it.

CunningFellow
Posts: 1196
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzem modifications

Post by CunningFellow » Wed Feb 25, 2015 11:06 pm

If it helps narrow it down t2k does not do any "FAT" reads.

It does everything low level. Just

Init
Cue sector
Read sector

So you can prob ignore anything on the AVR side of the debugging higher up than that.

Also the mods/compiles I did on uzem was

Eclipse
Mingw
WinXP 32

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest