Page 1 of 4

Uzem modifications

Posted: Mon Feb 02, 2015 2:58 am
by uberlinuxguy
Hello All,

I am working on another piece of hardware to add on to the uzebox, and as such, I wanted to modify the emulator to support it. (for the hardware, see http://uzebox.org/forums/viewtopic.php?f=3&t=2172) I haven't had much time to work on the hardware, and to get the bits I am working on working in the emulator, I needed to make some modifications to the SPI System in the emulator.

I've broken out the SPI bus bits from the SD/MMC code and separated the SD/MMC card stuff from the SPI bus stuff so I can extend the SPI bus stuff. I am using the SDCardDemo ROM to test consistency and the preliminary results are positive. I am curious if there are any other SD/MMC card tests I should be running to validate consistency. Thoughts?

Once I verify the SD/MMC works in the emulator, I am going to start implementing the SPI RAM stuff I am working on. (Also once I get the SPI RAM stuff working in hardware form.)

Re: Uzem modifications

Posted: Mon Feb 02, 2015 9:49 am
by CunningFellow
Try running Tornado2000.

As far as I know it's the only thing apart from the full motion video demo that has tight SD requirements. The video demo does not run in the emulator, so that leaves T2k

Re: Uzem modifications

Posted: Mon Feb 02, 2015 4:08 pm
by uberlinuxguy
CunningFellow wrote:Try running Tornado2000.

As far as I know it's the only thing apart from the full motion video demo that has tight SD requirements. The video demo does not run in the emulator, so that leaves T2k
CunningFellow: I tried to run Tornado2000 in my modified version and in the downloaded version from the site (1.17) for windows and both of them hang at a black screen. I can troubleshoot further, but it looks like it is something having to do with the sd card on both versions that it's hanging on.

** EDIT **
Having posted that message I just saw the release topic in here and it has 1.19. I will try that version next.

** Edit again**
1.19 works. Hmm. that's interesting. I will do some more testing on my modifications and see why it does not work. I wonder if there is a difference in the 1.19 source and what is in the trunk on the google code page.

Re: Uzem modifications

Posted: Mon Feb 02, 2015 8:59 pm
by CunningFellow
Try running leena.hex from here

http://uzebox.org/forums/viewtopic.php? ... =50#p11711

It needs the new interrupt features from 1.19 but does not need SD card

Re: Uzem modifications

Posted: Mon Feb 02, 2015 9:08 pm
by uze6666
Version 19.1+ implements a new interrupt that was required for Tornado. Running in in previous versions hangs the emulator as you noticed. All that is in the trunk.

Other SD apps to test:
-Alter Ego
-Uzeamp
-Thermometer demo
-Uze Mario
-Uze8 emulator

Btw, great news that you are refactoring the ISP/SD code. I have a rev to make on the PCB and was talking about including the SPI ram footprint in there (The Microchip 1Mbit, DIP-8). I think the hardware design is pretty trivial, but it's important we have the same, especially using the same CS pin. The upper nibble of PORTA is free so I'd recommend we use one of those pins, say PA7. We could have used PB2, but after thinking about it, it has an analog comparator and a external INT function on it that may come useful in the future.

Re: Uzem modifications

Posted: Mon Feb 02, 2015 11:40 pm
by uberlinuxguy
uze6666 wrote:Version 19.1+ implements a new interrupt that was required for Tornado. Running in in previous versions hangs the emulator as you noticed. All that is in the trunk.
This is a good hint. I will play around with that, I don't know if I actually did anything in the interrupt handler yet. I'll play with some of the other apps you mentioned.
uze6666 wrote: Btw, great news that you are refactoring the ISP/SD code. I have a rev to make on the PCB and was talking about including the SPI ram footprint in there (The Microchip 1Mbit, DIP-8). I think the hardware design is pretty trivial, but it's important we have the same, especially using the same CS pin. The upper nibble of PORTA is free so I'd recommend we use one of those pins, say PA7. We could have used PB2, but after thinking about it, it has an analog comparator and a external INT function on it that may come useful in the future.
I was looking to go full Monty and put 4 of 'em on a bread board, once I got one working, and go from there. From what I could gather, PA4 through PA7 looked open. I can code it so that it uses PA7 by default though (for "BANK 0")

Re: Uzem modifications

Posted: Tue Feb 03, 2015 10:40 pm
by uze6666
In my schematic I already had PA4 for the SRAM chip select. So lets us this one after all. It will also fit more logically with your "multi bank" mod.

Re: Uzem modifications

Posted: Tue Feb 03, 2015 11:42 pm
by CunningFellow
Would it be sensible to only allocate 2 pins for the 4 chips and have binary weighting

If your already having 4 x 8 pin dips hanging off the end, does a 74138 make much difference?

The single chip version would not need a 74xx chip, so it doesnt put any burden on that.

Re: Uzem modifications

Posted: Wed Feb 04, 2015 4:41 am
by uze6666
For the official version, I'll use only one chip. Anyone who want to expriment can add as much memory as they want and use as many logic as they see fit.

Re: Uzem modifications

Posted: Wed Feb 04, 2015 5:49 am
by CunningFellow
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 ?