512K cart board (PLCC) - Troubleshooting

[matthew180]

How much do you want?

[+retroclouds]

How much do you want?

 

I'd already by very happy with anything between 1K and 4K

[marc.hull]

How much do you want?

 

4K RAM and 4K ROM pages x whatever

[+retroclouds]

How much do you want?

 

4K RAM and 4K ROM pages x whatever

 

Would be nice if you could toggle the RAM on/off from inside your program.

For example at the start of a game, RAM would be turned off.

The matching 4K ROM could contain pattern/initialisation data to copy to the VDP. Then you toggle RAM on for storing/accessing variables, etc.

 

You get the picture

[marc.hull]

How much do you want?

 

 

My wish list for RAM/ROM cart......

 

4K RAM that is always apparent. This would give a programmer at least 3K of data storage as well as a 1K area for a memory manager to run in (doubt you would need near that much but I'm just throwing out numbers.) Although I have not done anything that utilized bank switching I can envision the load it would take off the programmer to have the supervisor always apparent as well as plenty of data....

 

I am NOT familiar with the current bank switching scheme so if I am talking out my ass here then please redirect me but it appears to work as a serial in/parallel out shift register which I can see being a bit of a PITA. Perhaps a new scheme that acted as a transparent latch MIGHT be better. In effect all the programmer would have to do is write a value to ROM. That value would be trapped in the latch and used as the offset or higher order address lines for the ROM. IE selecting bank 0 would be a write of 0 to any ROM address while bank 3 would be a write of 3 etc. All of this could be performed with a MOVB from the supervisor or other banks without calculating which bank was needed versus where you are. Kind of a set it and forget scheme. A return bank number could be stored in RAM as well as a return address and then banks could become in effect subroutines that returned to the correct location fairly painlessly.

 

A way to ensure that bank 0 is brought up first (I think this may all ready be done.) This way the memory manager and needed tables could be loaded and would not have to appear in all banks.

 

Keep the flash ram ! Damn good idea whom ever came up with that one. Shit can the GROM stuff. A 256K flash yields 128K of paged data at a ridiculously low price. More than enough for anything we do IMO.

 

86 all the jumpers etc unless you guys have plans to be able to program the flash from the TI (well do you ??) They seem to cause trouble .

 

The decoding/bank selection etc that I envision cost 3 logic chips so perhaps Matthew will work his FPGA magic to eliminate those. I wonder what an FPGA costs ? The needed logic chips (373,138 and 04) run about $2.50 onsey-twosey. If the FPGA isn't a whole lot more then the board size could also be reduce to save some costs so perhaps they will balance out.

 

Keep the board through hole. I can't afford anything more than my six dollar Radio Shack soldering iron and I can't see that well anyway.

 

Finally the winning lottery numbers might be nice and a new ass. Mine has a crack in it.

[John Doe]

Edited February 22, 2014 by Tony Knerr

[+InsaneMultitasker]

I may have asked and received an answer before... if so, sorry, memory is short these days.

 

I noticed the flash chip is of the 'F' variety. Was that chosen for a specific reason? I ask because the 'C' variety could allow for reprogramming at the chip 'sector' level versus a full wipe and reprogram, allowing the user to to everything from the TI. This assumes the hardware is capable of performing the program cycle from the cart port.

[+acadiel]

I'll defer some answers to Tursi and Ksarul.

 

About the F chip - Ksarul got a large (and I mean large) lot for dirt cheap. So that's the story behind that.

 

Don't know Tursi's plan for programming the AVR, but he's got those pins in the front for something. I know that most of the AVR pins needed for programming are being brought to the front of the board.

 

As for jumpers, it's a 512K chip. That's what you get. 512K. Don't know if there are any plans in the prototype to change it. Since Ksarul got such an amazing price on those 49F040's, you can simply fill up the part you need andnleave the rest available.

 

Anyway, I've spilled all the info (or misinformation) that I have right now.

 

And unless I'm wrong, apparently (?) with GROM emulation and the banked ROM, we might be able to use these boards for a new XB.

 

I'll shut up now and let the experts chime in.

[Tursi]

So is the Rom and Grom going to be accessable at the same time? For instance: Grom from >6000 to >FFFF with two 8k banks of Rom at >6000.

That would make it XB (and all but 1 of official TI carts) compatible. Been hoping for XB 2.5 in a cart for a few years now...

 

Yep, that's correct. I think reproducing XB was one of Jon's goals this time?

 

The GROM chip is intended to support multiple GROM bases, as well (4 or 8, I can't remember off the top of my head). As well, each "GROM" in the space can be configured - to point to GROM (about 120k to choose from), GRAM (8k), EEPROM (4k), or external hardware (serial port, timer and SPI). This is mostly coded, the last big task I have to code is the ability to erase and re-write the GROM banks. I needed all these features for my MPD and Linux projects, so that they'll end up in here is a nice side effect.

 

Coded and working are the multiple GROM bases, bank configuration, EEPROM read and write, and GRAM read and write. Proven to work in practice but not implemented in final is the serial port hardware. Coded but not proven is the timer. Not started is the SPI or GROM erase/write code.

 

Most carts won't need most of these features, but they are available for the cost of a few lines of software! The SPI should make it possible to (for instance) hook up an SD card to the GROM port, as well as plenty of other embedded devices, and the serial port is also handy for communication with embedded hardware, if you want to drop it in a cartridge. For instance (not something I plan to show but something I've tested briefly), if you wire the serial port up to an XPort device (http://www.lantronix.com/device-networking/embedded-device-servers/xport-direct-plus.html), you can have a full ethernet-based internet stack in a cartridge.

 

At least, that's the plan.

[+Ksarul]

I did get a good deal on the "F" chips--I got about 2500 of them for less than a quarter each. That should be enough to make a LOT of cartridges. <LOL> I've also made a lot of updates to the board itself in response to suggestions and requests from Jon and Tursi. I still need to know whether or not the position I moved one of Tursi's caps to is good though--as that will let me do a short run of boards with all of his needs incorporated. I also have a goodly number of the necessary GALs on their way. Now I just have to figure out if my hardware will let me program the 1284s. . .

[+acadiel]

Marc, you can thank Matthew for the 512K GAL. He adapted his 379 replacement and just extended it with two more sets of I/o pins.

 

Anyone for making a TI megademo?

 

Here's the latest revision that Ksarul has been working on. This is still prototype stuff, guys, and yeah, I don't think you can cram much more on that cart board.

 

Onboard, there is a Lattice GAL16V8, that takes the place of the 74LS379, but lets us bank switch 512K (adds two more sets of I/O lines) in the 49F040 flash ROM. Thanks to Matthew, we have the code needed to burn these, but haven't actually burned one yet. No worries, it should work. Ksarul took the pin output that Matthew provided and used it, so as long as we don't make any changes, the pins should be fine.

 

The ATMega 1284 is the GROM emulation, and you can thank Tursi for that work, he's done a great job, and proved it at last year's TI Faire with his demo. There's a bunch of I/O jumpers to interface with the ATMega, so just about anything is possible. That's a pretty powerful AVR [8 bit RISC] for the machine it's interfacing with! We can do GROM, GRAM, the thing has some EEPROM as well as Flash, you name it...

 

And, also thanks to Ksarul, we have a boatload of 49F040 Flash and GAL16V8's for parts.

 

I'm anxiously awaiting the next prototype board run to see how well it works

Edited June 30, 2011 by acadiel

[+retroclouds]

That sure looks impressive. Looking forward finding out more about what this little beast can do

[Willsy]

Wow! Amazing job! Getting all that on a double sided board within the size constraints is really quite something. Hats off to the layout guy!

 

Mark

[+acadiel]

Oh yeah, and it does have 16K of RAM for those of you who have been requesting it. 4K of EEPROM and 128K of flash as well. Not sure how it all will be implemented yet though. Tursi's working on that part

[+acadiel]

(The Atmel chip, that is)

[Tursi]

The RAM is not CPU RAM, so it's not actually what people have been requesting (and only 8k is available, not 16k. It needs some of the RAM to run the emulation code after all!) The AVR always answers as a GROM. I/O is managed by reads and writes to GROM space, so it's like memory-mapped devices. The multiple data is handled through special writes that cause page-flips, so you can page the GROM, GRAM, EEPROM and devices in and out in real time. The only thing I haven't worked out to my liking yet is how to partition the GROM space to keep wasted space at a minimum while still being flexible on GROM sizes - the current code builds all the ROM data into the program.

[+acadiel]

The RAM is not CPU RAM, so it's not actually what people have been requesting (and only 8k is available, not 16k. It needs some of the RAM to run the emulation code after all!) The AVR always answers as a GROM. I/O is managed by reads and writes to GROM space, so it's like memory-mapped devices. The multiple data is handled through special writes that cause page-flips, so you can page the GROM, GRAM, EEPROM and devices in and out in real time. The only thing I haven't worked out to my liking yet is how to partition the GROM space to keep wasted space at a minimum while still being flexible on GROM sizes - the current code builds all the ROM data into the program.

 

Ah, that explains things - the RAM is for the AVR itself, not for our usage

 

Still, GROM/GRAM and EEPROM probably would give us a whole heck of a lot. Imagine Owen making a super mega Beryl RPG :)

[marc.hull]

The RAM is not CPU RAM, so it's not actually what people have been requesting (and only 8k is available, not 16k. It needs some of the RAM to run the emulation code after all!) The AVR always answers as a GROM. I/O is managed by reads and writes to GROM space, so it's like memory-mapped devices. The multiple data is handled through special writes that cause page-flips, so you can page the GROM, GRAM, EEPROM and devices in and out in real time. The only thing I haven't worked out to my liking yet is how to partition the GROM space to keep wasted space at a minimum while still being flexible on GROM sizes - the current code builds all the ROM data into the program.

 

Ah, that explains things - the RAM is for the AVR itself, not for our usage

 

Still, GROM/GRAM and EEPROM probably would give us a whole heck of a lot. Imagine Owen making a super mega Beryl RPG :)

 

I'm trying to imagine a cart with some CPU RAM. Gonna happen or not ??

[Willsy]

I'm trying to imagine a cart with some CPU RAM. Gonna happen or not ??

 

It would be nice wouldn't it? Even 1K, mapped (optionally) into the top of the cart memory space (>7C00 to >7FFF) would be nirvana. Anyone that has done any hard-core cart development will know exactly what I'm talking about. The option to page the memory in/out would be nice. However, the design looks to be in a very advanced stage of development. It may be too late. Also, looking at the PCB layout, it's getting wuite crowded. The only available space is in the bottom right hand corner. It may be possible to physically get a through-pin device into that space, but you've still got to get the tracks to it. It'd be tricky I reckon. Question: Was the board laid out manually or by using an auto-router?

 

Perhaps an alternative to straight RAM might be a port mapped RAM? Using this approach some of the RAM on the Atmel could be used (it would need software to be written on the Atmel side). One could use the same technique as one uses to read/write VDP. Three memory addresses would be required:

 

Address port (10 bits for 1K, might as well make it a 16 bit wide address)

Write port (8 bits?)

Read port (8 bits?)

 

It's better than nothing! And would (presumably) require no changes to the current hardware design?

 

Some sort of software handshake would be required, since the Atmel and the 9900 are free-running with respect to each other. For example, if you write an address to the address port, how does the Atmel know if you want to do a read or a write? Well, I suppose reads don't matter too much, it could just blindly do a read and populate the read port. But how does it know when you want to do a write? Something would need to be designed in to get around that issue, methinks!

 

Anyway, I'm really looking forward to GROM read/write access in a cart. It's the perfect place for graphics etc, though with 512K of flash, we're not exactly short of space!

 

Mark

Edited July 1, 2011 by Willsy

[+Ksarul]

The boards were manually routed, Willsy. I put the basic design elements into my head and do the auto-routing there, as I seem to be able to do a reasonably good job of it that way.

 

I did put in an order for a small number of boards using the revision 8J template Jon put up, as it is pretty much the final revision unless we discover any problems with this proto run. I'll have the boards in hand by the end of the month, though I may not be able to do much with them until September, as August is pretty busy for me this year due to work/family commitments.

[Tursi]

Perhaps an alternative to straight RAM might be a port mapped RAM? Using this approach some of the RAM on the Atmel could be used (it would need software to be written on the Atmel side). One could use the same technique as one uses to read/write VDP. Three memory addresses would be required:

 

8k of RAM on the Atmel is available as a pageable GRAM. (Which you access with similar mechanisms to VDP). You can read/write it at will when it's mapped in, and map it in and out dynamically into GROM space.

 

Sorry this was unclear.

 

Some sort of software handshake would be required, since the Atmel and the 9900 are free-running with respect to each other. For example, if you write an address to the address port, how does the Atmel know if you want to do a read or a write? Well, I suppose reads don't matter too much, it could just blindly do a read and populate the read port. But how does it know when you want to do a write? Something would need to be designed in to get around that issue, methinks!

 

The GROM interface handles all this. It is very important that the Atmel knows when a read happens, since it may not drive the data bus if it's not the chip being accessed. The whole TI has only one data bus. 9900, VDP, ROM, RAM, GROM, DSRs, cartridges, PEB, etc, they all share this one bus. At any rate, this has all worked for a long time now, I first released the GROM emulation about 9 months ago, and the MPD demonstration I showed on YouTube uses the RAM (the CALL DIR function uses 2k of it!)

[marc.hull]

and the MPD demonstration I showed on YouTube uses the RAM (the CALL DIR function uses 2k of it!)

 

What is using the RAM ? The uC or the 9900 directly ?

[Tursi]

and the MPD demonstration I showed on YouTube uses the RAM (the CALL DIR function uses 2k of it!)

 

What is using the RAM ? The uC or the 9900 directly ?

 

The uC uses a small amount of RAM for the emulation code. (On the order of a few bytes, but I will need more when I get the rest of the peripherals coded).

 

The 9900 also has access to a block of 8K of the AVR RAM, but this is still on the GROM bus. So you read and write to it through the 9800/9C00 addresses.

 

In my MPD code, the CALL DIR function backs up a block of VDP RAM to the AVR's RAM block in order to work without needing to allocate buffers or memory (or worry about the memory differences between TI BASIC and Extended BASIC). When it's done, it just puts the data back. I don't think CALL DIR is in the video, I should make a new one...

[+acadiel]

Can Multicart be enhanced to use the RAM to buffer the whole 40 something 8K ROM carts without switches now? (I think you said it was tight with the VDP scratchpad, so can we can offload it to the AVR now?)

[Tursi]

Oh, you mean the multicart software? I don't remember thinking that VDP memory was tight, but my main concern at the end, anyway, was I didn't want to write the code to handle scrolling or paging.

 

I don't have the ability to commit to anything new for a couple of months, but I think we can do this if I can find my original source.

 

No need to offload to the AVR, I don't think. Best if we don't since not every cart will have it.