Uzem modifications

The Uzebox now have a fully functional emulator! Download and discuss it here.
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Uzem modifications

Post 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.)
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzem modifications

Post 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
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: Uzem modifications

Post 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.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzem modifications

Post 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
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzem modifications

Post 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.
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: Uzem modifications

Post 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")
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzem modifications

Post 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.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzem modifications

Post 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.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzem modifications

Post 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.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzem modifications

Post 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 ?
Post Reply