Jump to content
IGNORED

How is bank switching implemented in a Multi-Cartridge?


retro_doog

Recommended Posts

OK, I admit this is somewhat of a loaded question. I fully understand the concept of bank switching in general, but what I'm trying to figure out is what operations are performed on cartridges to actually perform the bank switching. For instance, writes to a couple of particular addresses(I forget offhand, maybe >6000, >6002?) will perform bank switching of the upper half of the 8K Cartridge ROM space which is how Extended Basic Cartridges use this feature. But, I'm not clear on the software mechanism the various bank switched "Hobby" cartridges use for bank selection. I've read up on the use of the 74LS378 and LS379 Hex and Quad latches as well as the issue of indeterminite power-on states etc, but how do those latches get written? Is there a special address being used or is it leveraging off of the same address that EB uses for it's bank switching, only using more of the bits?

 

Secondly, I see demos of various multi-carts with multi-title custom menu screens and that raises a few more questions:

 

1. Are these "Launchers" as I'll call them written in assembly? Have any been also written in GPL?

2. Is the list of ROMs hard coded into the program, or does the console have a way of "scanning" for all titles present?

3. I'm assuming the launcher takes a selection and uses that to write the appropriate bank switch value, what next? Is the console reset with that bank selection making is appear as if the single bank switched cart is now the only one present? Or does the launcher somehow select the bank and automatically jump to the proper launch point for that cart? What if the cart had multiple titles/languages?

 

Feel free to hit me with the technical facts. I'm well versed in hardware design(20 years experience), and have fine software skills in general, but I've never delved into GPL or TI assembly programming. I wrote all my programs in plain (not extended) TI-Basic back in '83 when I got my first TI-99.

 

The reason I'm finally inquiring about these details is because I'm launching a new multi-cart design of my own. I definitely plan to incorporate two big improvements:

1. The ability to mix and match ROM, GROM, and ROM+GROM titles on the same cart, hopefully being able to even accommodate EB and it's required "live" bank switching.

2. A sort of "directory" type structure where we're not wasting the unused 2K tail of each GROM. The GROMs will be in sort of a linked-list structure with better base address translation.

3. I'm hoping to add Mini-Memory style optional RAM as an extra "flagged" option in the directory structure.

4. I want to use all surface mount, permanently mounted parts and have a USB port on the cart itself to allow uploading ROMs. Eventually I'd like that interface to evolve into a desktop mounted flash drive that you simply drag binaries onto and perhaps update an XML file that the launcher has access to.

 

I would have liked to incorporate a lot of the functionality of the CF7 right into the cartridge, like the 32K expansion and have a CF slot in the front of the CART(Or better, SD card nowadays), but it appears that the cart slot is missing many of the signals that would be needed to incorporate these features. If I'm wrong on this point, please correct me!

 

My prime goal is the ability to store a library of existing legacy titles on one cart. I realize some of these bank switched carts actually accommodate new programs that are written of take up more than the 8K+40K limitation by performing "live" bank switching while running. I'm not sure my first iteration will accommodate this, but I'll keep all things in consideration as I delve into this. Also, I'm motivated to crank this out on an accelerated schedule, so it doesn't become one of those Vaporware projects that people pine for for years that eventually get dropped due to lack of time, etc. Any info would be appreciated as I get this started. I'm hoping to have an early prototype developed within a month!

 

Thanks to all who provide help and moral support :D

 

 

PS. Why does the TI community use '>' to denote hex addresses instead of '$'. Is it just due to the TI documentation/EA cursor prompts? Just curious.

Edited by retro_doog
  • Like 2
Link to comment
Share on other sites

There are a lot of answers to your questions. The first one, how does the TI use bank switching, is the easiest to answer: you write to the cartridge space at an even address to select the bank you are looking for:

 

>6000, >6002, >6004, >6006, etc., up to the maximum available bank in the cartridge. The largest bank-switched cartridge I build right now has 256 of these 8K banks. TI only switched the upper 4K of the bank for modules like Extended BASIC, later schemes just switch the entire 8K (and put the first 4K of the XB ROM in both banks so that it works just like it would on a TI board). Note that that only solves half of the cartridge board problem. You have to have something to simulate the GROMs. TI used a set of four 74LS161s and some additional logic to simulate the GROM chips' 13-bit self-incrementing internal address registers. Tursi wrote some code to emulate that in software for the ATMEL ATmega series of chips. We use that on an ATmega 1284P to provide up to 15 GROM slots (basically a place to put the contents of a GROM chip (works with 6K or 8K GROMs)). The UberGROM cartridge board incorporates that and puts an additional 512K of bank-switched ROM on the board to allow it to replicate hybrid ROM/GROM cartridges. We've got images out there for cartridges that use that entire 640K of space, with a mix of old and new software. One of them even includes TI XB as a possible selection (it also has RXB 2015 and Tony Knerr's XB 2.7 in it).

 

There are now about half a dozen different cartridge boards in production (I work to keep all of them continuously available), with one more in development (not counting yours). Only one of those will simulate GROM in addition to ROM (the aforementioned UberGROM). To get the additional signals you want, there is no choice but to build a board that connects to the side port as opposed to the cartridge port--and the side port will recognize GROM too, as the developers of the various GRAM cards for the PEB demonstrated (and TI used that capability too with the p-Code card and its 8 GROMs).

 

The menu software is custom coded for each cartridge image using a menu template developed by Tursi and Acadiel. You plug the program's code into the appropriate bank(s) of the ROM, set the menu selection for the start bank of the program, and one of two things will happen: the program will execute from ROM (as it is fully compatible with the board--generally 8K programs or programs written with these boards in mind) or it will lob the program into the 32K space and execute it from there. Note that GROM programs may be tossed into 32K space and executed through a software GROM emulation (if they were small enough to fit in the 32K space along with the GROM loader) or they may execute from GROM (using the UberGROM). Note that the programs generally begin execution directly if launched via the loader/launcher. A GPL version of the launch menu program exists for the UberGROM board, and has the added bonus of being able to force the 74LS378 to >6000 as its power-up bank as part of the console's power-up routine. This option doesn't exist for ROM only boards, as the power-up routine must reside in GROM to be recognized. The cartridge board in development will resolve the starting bank issue using some different chips, but it will remain fully compatible with the 74LS378 boards and images.

 

None of the existing boards incorporate the 4K of RAM found in the Mini Memory (or the 1K of RAM used in the MBX cartridges either).

  • Like 1
Link to comment
Share on other sites

Thanks Ksarul! I figured it would be one of the cart developers who would have the answer.

 

So, even addresses since a 16-bit architecture doesn't have an A0 (Or A15 in the TI-99's case?). So a write enable is used to latch the lowest n address lines to allow for bank selection of 2^n banks? I get that I'll have to do GROM emulation, and I also plan to use an AVR, but instead of using the AVR's internal flash and being limited to 128K, I'm going to link a small AVR(Probably a 20-pin ATTiny part) to en external flash chip to allow more than 16 GROM banks. I'll probably have two separate flash chips on board: one for ROMs and one for GROMs and I'll feed the bank number into the AVR. I'll probably try to latch the bank number into the AVR directly, although that might bump me up to a 32-pin ATMega part. I'm pretty good at optimizing hardware, so that will be a fun challenge ;-)

 

So now that I know there's no magic to the launcher menu, that will likely be the trickiest part of the process as I'll have to either learn how to program assembly or at least start with a source code base and adapt it to something that works on the new hardware. Im also pretty good at that. I took an existing Palm OS multi-emulator and added a lite version of PalmMAME to the suite. Assembly will certainly be tricker than C of course.

 

Thanks again for your help :-D I'll be sure to keep the forum posted on my progress.

Link to comment
Share on other sites

Forgive me touching on points all at once, maybe with some repetition. :)

 

Same deal on the 378/379 as with XB -- a write to an even address latches a new bank. The address bus is what is latched, the data is irrelevant. The only difference versus XB is the homebrew carts switch the entire 8k space rather than just 4k. There's enough room on the address bus for up to 12 bits of address, which gives a potential maximum of 32MB for this scheme (but the largest cart so far I am aware of is 2MB).

 

My "Multicart Menu" is written in assembly. The menu that Gazoo wrote for XB27 is also assembly. I don't know about others.

 

In my menu, the list is built at runtime by scanning the banks. Gazoo's was hard coded. Neither uses any built-in console scanning. The console can scan 1 ROM and up to 5 GROMs. Each of these can contain an unlimited number of program entries - however the console does not have any code to deal with running off the bottom of the menu screen. Up to 16 GROM bases can be selected one at a time with the base switched using "REVIEW MODULE LIBRARY" as an extra selection.

 

How programs are started varies depending on the program. The correct bank is first selected, and then:

 

-some programs run directly from ROM. In this case, the menu just jumps to the start address.

-some programs need to run from RAM. In this case, the menu program copies the data from ROM to RAM and then jumps to the start address in RAM. This copy is usually hard coded.

-some programs run from GROM. In this case the GROM addresses are set up and the console GPL interpreter is resumed to run the program. In my menu this is accomplished by restoring a backed up copy of the scratchpad RAM, setting R6 to the GPL address, and branching to >0060, which loads the address into the interpreter and executes.

 

You should be aware that only official TI GROMs waste the last 2k of space -- most homebrew GROMs use the full 8k of space.

 

And yes, the cart slot is missing the signals needed to make it useful as a general purpose expansion port. In particular it can only see 8k of the address bus (with an extra signal to notify when it's in cartridge space), so non-GPL DSRs are right out. :/

 

As for Karsul's note of a GPL version of the launch menu -- it's only a GPL loader. It sets the correct bank and branches to the ROM-based version of the menu, the menu itself is still not in GPL. I did this to solve the issue of the wrong bank being active on reset, if there's a GROM there anyway. ;)

 

The reason for even addresses is that every read or write to the TI's 8-bit bus /always/ accesses both the even and odd addresses. As you note, there's no A15 on the 9900. But the 8-bit bus needs one, so it simulates it by turning every memory access into two. By ignoring the LSB, you don't have to deal with the issues of double-access that this creates.

 

Also worth noting -- the reason my AVR limits to 16 GROM banks is arbitrary. The console ROM only scans 16 banks, and with only 120k of flash it's not possible to fill all the slots anyway, so there was no need to map more. According to Thierry Nouspikel's page, it should be possible to map up to 256 banks of GROM.

 

Good luck and have fun with it!

  • Like 1
Link to comment
Share on other sites

Hi Tursi,

 

All great information. Sometimes repetition is a good thing when it adds clarity :)

 

I did understand that the main reason for the 16 GROM banks was due to the 128K Flash in the chosen AVR. What I did not know was that the console will scan the alternate GROM banks above 9800/9C00. I thought I had read that by default the console ROM will only look in the 8 'slots' of the first bank and not the alternate 5-per bank GROM 3-8 'slots' in the alternate banks. Is this automatically done(outside of having a custom menu launcher)? In other words, if I were to theoretically make a multi-cart that contained GROM only titles and emulated the different titles which share the same base address in alternate banks, the stock console loader would show them all(provided I didn't go off the bottom of the screen)? Not that it's my intention to make a cart with those limitations, I'm just trying to understand the console a little better.

 

So your menu loader will scrub though the descriptors at the beginning of each ROM banks "cartridge" and build the list dynamically? WIll that also work with bank switched GROMS? That is, GROMs that are switched into the default 9800/9C00 bank at GROM3 Base via a mechanism like the address bus 74LS37X latch. Just trying to get a feel if your loader will work with no mods provided I architect the ROM/GROM structure accordingly.

 

My plan is to not exactly use the address driven bank switch as a raw address selection translator, but to use it as a "Title Selection Bus". So, for instance, if you have a title that has 1 or more ROM banks combined with one or more GROMs in the original cartridge, selecting that "Slot" via the bank switch latch will load ALL of the required resources into the proper base addresses in on the TI-99s address bus. With Battery RAM added to the cart, there will even be the possibility of having a virtually identical Mini-Memory as one of the options, as choosing that would posit the Mini Memory GROM, the 4K ROM, and the 4K RAM into their proper locations on the bus. The AVR will orchestrate everything by selectively routing all of the raw resource chip selects as well as doing address translations and doing the work of the GROM auto-incrementer. I plan to have some sort of descriptor table in the AVR EEPROM if it fits that signifies which ROMs go with which titles as well as a flag for the presence of RAM so that new Mini-Memory type carts can be made in the future. The whole thing will be designed as one monolithic architecture as opposed to having separate systems play ROM bank switch and GROM emulation, which should make this sort a beginning of the ultimate cartridge end-game. I'll probably even make it possible to have two 8K RAM banks if a GROM only new title wants access to that much RAM on cart. Everything is going to be surface mount components and I'll be able to fit a lot of stuff inside the cart and it will all likely draw a fraction of the power that a stock cartridge draws. My initial attempts will be AVR based, but if I need the horsepower, I may step up to an ARM Cortex M0+ if only for it's ability to slog around 32-bits of data at a time.

 

Again, thanks for all the info! The response time on this board is pretty amazing :-D

 

When I get to the menu writing part of this I may need quite a bit more help, so If any of you are interested, I'll provide free beta test boards to those who volunteer to help with the menu program. But we're a little ways from that at the moment.

Link to comment
Share on other sites

I would have liked to incorporate a lot of the functionality of the CF7 right into the cartridge, like the 32K expansion and have a CF slot in the front of the CART(Or better, SD card nowadays), but it appears that the cart slot is missing many of the signals that would be needed to incorporate these features. If I'm wrong on this point, please correct me!

I think the 32K Memory Expansion areas are only exposed on the side-port and not at the cartridge-post.

 

Personally I would like to see the $5 Raspberry Pi Zero used in a super-cartridge and in a super-expansion (side-port). This guy replaced the disk-drive in his Amiga with a Raspberry Pi.

 

;-)

  • Like 1
Link to comment
Share on other sites

I did understand that the main reason for the 16 GROM banks was due to the 128K Flash in the chosen AVR. What I did not know was that the console will scan the alternate GROM banks above 9800/9C00. I thought I had read that by default the console ROM will only look in the 8 'slots' of the first bank and not the alternate 5-per bank GROM 3-8 'slots' in the alternate banks. Is this automatically done(outside of having a custom menu launcher)? In other words, if I were to theoretically make a multi-cart that contained GROM only titles and emulated the different titles which share the same base address in alternate banks, the stock console loader would show them all(provided I didn't go off the bottom of the screen)? Not that it's my intention to make a cart with those limitations, I'm just trying to understand the console a little better.

Yes. And no. :)

 

The console first attempts to determine if you have a multi-base GROM cartridge by comparing 32 bytes at GROM address >6000 first at base >9800, and then at base >9804. If they read the same, then the console assumes that there is only one base in the cartridge (which is how all official carts were), and will no longer attempt any base except >9800.

 

If they differ, however, it will add an option called "REVIEW MODULE LIBRARY" to the bottom of the list. Selecting this option will increment the current base by 4 (so >9800 becomes >9804) and it will display the contents of that base, if any. Empty bases are skipped, and it will wrap around after 16 bases are checked.

 

You can see this in Classic99 by creating custom carts in Classic99.ini, using "G" as the type tag for the first base, "G2" for the second, "G3", etc.

 

Note that there is a bug in the scan routine wherein if a valid title can't be found in the first base and bases are detected to be active, the console just spins looking for it instead of displaying the list.

 

It's also worth noting that there are LOTS of GROM titles that do not work at a base other than >9800 - particularly those which combined with ROM. The multiple base concept appears to have been "left in" rather than formally supported, and many official titles hard code the GROM access address rather than checking where it was booted from.

 

So your menu loader will scrub though the descriptors at the beginning of each ROM banks "cartridge" and build the list dynamically? WIll that also work with bank switched GROMS? That is, GROMs that are switched into the default 9800/9C00 bank at GROM3 Base via a mechanism like the address bus 74LS37X latch. Just trying to get a feel if your loader will work with no mods provided I architect the ROM/GROM structure accordingly.

ROM and GROM, yes. But there are no bank switched GROMs today (and I'm not entirely sure how you mean to bank them in), so no, there's no code in there to support that concept. :) The search loops are pretty simple and easy to extend though.

 

My plan is to not exactly use the address driven bank switch as a raw address selection translator, but to use it as a "Title Selection Bus". So, for instance, if you have a title that has 1 or more ROM banks combined with one or more GROMs in the original cartridge, selecting that "Slot" via the bank switch latch will load ALL of the required resources into the proper base addresses in on the TI-99s address bus.

Makes sense. I was going to release a version of the Ubergrom that does similar, since people would rather make Multicarts than new carts. ;) That doesn't give it RAM, though.

 

The only thing to watch in your design -- a raw AVR is not fast enough to respond to the CPU memory bus. You can use it for latching and you can access it over the GROM bus (which waits, and the AVR is easily faster than real GROM anyway), but you'll need something faster than at least a 20MHz AVR (fastest I tested) to keep up with CPU accesses. This means the bank switching itself may still need separate hardware. (I did the math somewhere once, I think 50Mhz AVR would do it, but I figured if I went that direction a cheap ARM would be easier to get the performance out of.)

Link to comment
Share on other sites

 

I think the 32K Memory Expansion areas are only exposed on the side-port and not at the cartridge-post.

 

Personally I would like to see the $5 Raspberry Pi Zero used in a super-cartridge and in a super-expansion (side-port). This guy replaced the disk-drive in his Amiga with a Raspberry Pi.

 

;-)

 

Raspberry Pi is overkill for that application and a virtual waste of computing resources. The Pi is capable of emulating the entire system at full speed, I would suspect. I think a Cortex M0+ or Cortex M3 running at 100MHz sans all the Linux overhead would have no problem emulating hard drives, floppy drives, and all of the low speed I/O. In fact, one of my upcoming projects is to make a solid state SCSI drive replacement that is a little more streamlined than the current IDE?SD Card offerings.

Edited by retro_doog
  • Like 2
Link to comment
Share on other sites

The console first attempts to determine if you have a multi-base GROM cartridge by comparing 32 bytes at GROM address >6000 first at base >9800, and then at base >9804. If they read the same, then the console assumes that there is only one base in the cartridge (which is how all official carts were), and will no longer attempt any base except >9800.

...

It's also worth noting that there are LOTS of GROM titles that do not work at a base other than >9800 - particularly those which combined with ROM. The multiple base concept appears to have been "left in" rather than formally supported, and many official titles hard code the GROM access address rather than checking where it was booted from.

 

...

 

 

Makes sense. I was going to release a version of the Ubergrom that does similar, since people would rather make Multicarts than new carts. ;) That doesn't give it RAM, though.

The only thing to watch in your design -- a raw AVR is not fast enough to respond to the CPU memory bus. You can use it for latching and you can access it over the GROM bus (which waits, and the AVR is easily faster than real GROM anyway), but you'll need something faster than at least a 20MHz AVR (fastest I tested) to keep up with CPU accesses. This means the bank switching itself may still need separate hardware. (I did the math somewhere once, I think 50Mhz AVR would do it, but I figured if I went that direction a cheap ARM would be easier to get the performance out of.)

Ah, well I'm likely to just put the GROMs for the selected title only at 9800/9C00 for guaranteed compatibility. I'm definitely not going to try and emulate the CPU ROM in the AVR, however. Since the ROM is always in 8K chunks, I'll have the AVR "intercept" the latched bank number written and then have the AVR set the high address bits on the flash chip to select the appropriate ROM sector for that title. So, the ROM images won't need to correspond 1:1 with the bank number, nor will they even need to necessarily be in acending order! This could be handy if I can approach an end game where a linked list directory structure holds the cart information and a USB link can be used to load or delete new titles as desired.

 

I found a great SQI Flash chip with a 4-bit serial/parallel address/command/data bus This should make for a great GROM emulator when controlled by the AVR. Once you hit the sequential data phase, the ave will just simply clock out the new bytes, either by double clocking and latching every other nibble to make an 8-bit data bus from the 4-bit, or by putting two identical chips down to cover an 8-bit data width. I'll use a conventional parallel address separate data flash chip for the CPU ROM. My first iteration of the cartridge will likely just have a SPI bus header for programing the onboard flash chips. I'm about to release a handy LPC1768 MBED development platform I designed to the PCB Fab and that has a small OLED display and a bunch of I/O including a SPI/I2C expansion port. This will allow me to quickly mock up ROM files and use the MBED board to flash the cartridge until I work out how to do a USB loader on a later revision.

 

All of this info and interest is pretty motivating! I think I could have the hardware architecture figured out within a week and start on the schematic/pcb soon! Thanks again for the support :-D

  • Like 4
Link to comment
Share on other sites

Raspberry Pi is overkill for that application and a virtual waste of computing resources.

 

Ha ha, that is funny. All a matter of where you draw the line etc. ;)

 

With the Zero at $5 I think one could work out a very flexible friend. I don't think it would have to be a waste of computing resources. Upfront I have tons of ideas. Consensus around here is that the TI with the F18A is still a TI and in fact more or less a standard with owners (according to the polls). As of 2012 the F18A gives access to a duplicate CPU (more or less) running 50 times faster. It's mostly just sitting there. Nice potential for a good chess game and much much more.

 

I'll try stay out of this not to derail. Hope we're all okay. :)

Edited by sometimes99er
  • Like 1
Link to comment
Share on other sites

 

Raspberry Pi is overkill for that application and a virtual waste of computing resources. The Pi is capable of emulating the entire system at full speed, I would suspect.

 

Suspicion is good, trying is better. :) The Raspi (1) miserably failed to run the MESS TI-99/4A emulation (lacking 5 times the speed at least). But this largely depends on the emulation depth.

 

http://atariage.com/forums/topic/232622-raspberry-pi-and-emulation/?p=3195592

 

http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=98654

  • Like 1
Link to comment
Share on other sites

 

Ha ha, that is funny. All a matter of where you draw the line etc. ;)

 

With the Zero at $5 I think one could work out a very flexible friend. I don't think it would have to be a waste of computing resources. Upfront I have tons of ideas. Consensus around here is that the TI with the F18A is still a TI and in fact more or less a standard with owners (according to the polls). As of 2012 the F18A gives access to a duplicate CPU (more or less) running 50 times faster. It's mostly just sitting there. Nice potential for a good chess game and much much more.

 

I'll try stay out of this not to derail. Hope we're all okay. :)

 

Sure, that's why I specifically use the therm "Computing Resources" and not money. I'm a big opponent of hardware/software overkill. A 1Ghz Arm A-Class processor running Linux is a seems excessive for hardware to hardware emulation. Strip out the Linux and you can do the same with a 100Mhz Cortex-M. Still, the zero packs a lot of power for the dollar. The problem with trying to use that raw processing power when interfaced to the older hardware is that the bottleneck is the older machine's bus which will prevent you from properly taking advantage of that processing power.

 

Still, everyone has their platform preference. I have no problem with that, but sometimes people are not aware of simpler solutions, so I simply aim to educate when I can. All discussion is welcome, I'm sure there are technologies out there that I'm not aware of yet that may serve a purpose for my projects. :)

Edited by retro_doog
  • Like 1
Link to comment
Share on other sites

 

Suspicion is good, trying is better. :) The Raspi (1) miserably failed to run the MESS TI-99/4A emulation (lacking 5 times the speed at least). But this largely depends on the emulation depth.

 

http://atariage.com/forums/topic/232622-raspberry-pi-and-emulation/?p=3195592

 

http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=98654

Oh, I have no problem believing that. The Apple II emulator that is packaged with RetroPi is awful! And that's just trying to emulate a simple 8-bit 1Mhz system with nothing as convoluted as as the 99's VDP. Consider, however that Ed Schwartz's V9T9 ran at full speed on a 486/66DX under DOS. That was sort of my point I was trying to bring light to. I suspect that because of the amount of diverse hardware that MESS supports and it's way of "driverizing" multiple platforms, it's probably not the most efficient emulator. I've been deep into the guts of MAME and how it emulates, so I suspect MESS is very similar. Still, when my 700Mhz 1st generation Pi can't emulate a dedicated Apple IIe emulator anywhere near at speed, my suspicion is that Linux(raspbian) is getting WAY in the way. That's why one of my winter software projects will be to port the emulators in RetroPi to be able to run closer to bare metal. My aim is to make a launcher that runs bare and to create C-libraries that perform some of the various linux graphics and input libraries so that newer versions of the emulator code can be later be re-compiled without needing to change the sources significantly. Also, I want to make a gameboy sized platform that can tun the same suite on a 3.5" screen with only an ARM Cortex M3 or M4(If I find that the emulation needs hardware FPU for things like vector graphics emulation or similar).

 

Again, many people like that the Pi is cheap and they like/are familiar with Linux programming. Or, maybe they aren't and Linux allows them to just ./confgure, make other sure code with relative ease, but I like to find counter solutions to the mantra of "just buy the Pi2, it's faster" and find ways of getting more performance out of the current or lesser hardware since I know what the 16 and 32-bit older architectures were more than capable of emulating even at only 66-133MHz.

Edited by retro_doog
  • Like 1
Link to comment
Share on other sites

I've been deep into the guts of MAME and how it emulates, so I suspect MESS is very similar.

 

Yes, MESS is just a collection of drivers using the MAME core. The repositories were merged some time ago, and for some months now you don't get a precompiled MESS anymore - everything is inside MAME.

 

As I said, it really depends on the degree of emulation. I'm mainly concerned with the TI emulation in MESS, and we do not really long for efficiency. The goal is to get as close as possible to the circuit level, so instead of providing the GROM space as a list of bytes with a simple counter, we have GROM circuit emulations where you have to operate the proper signal lines, and the outgoing READY line causes wait states in the emulated processor.

 

I just wanted to say that the efforts for emulation should not be underestimated, and you have to decide how far you want to go.

  • Like 1
Link to comment
Share on other sites

 

Yes, MESS is just a collection of drivers using the MAME core. The repositories were merged some time ago, and for some months now you don't get a precompiled MESS anymore - everything is inside MAME.

 

As I said, it really depends on the degree of emulation. I'm mainly concerned with the TI emulation in MESS, and we do not really long for efficiency. The goal is to get as close as possible to the circuit level, so instead of providing the GROM space as a list of bytes with a simple counter, we have GROM circuit emulations where you have to operate the proper signal lines, and the outgoing READY line causes wait states in the emulated processor.

 

I just wanted to say that the efforts for emulation should not be underestimated, and you have to decide how far you want to go.

 

I totally get what goes into emulation. That's the difference between it and simulation. I can't speak to how Ed Schwartz implemented GROMs in V9T9, but I've been playing with emulators since the early 1990s and there were a lot of pure emulators that ran well on my 68030 and 68040 macs and even more that ran well on the first generation of PowePC processors. I've been a huge fan of Richard Bannister's work from way back.

 

Also, I have a great understanding of proper hardware description languages as I worked on ASIC designs for nearly 10 years in both VHDL and Verilog. I'm not sure if anyone writing emulators has any background in that, but I believe that an emulator written in an event driven method similar to how HDL simulators are implemented, will end up with a more compact, easy to follow, and more efficient emulator. I'm sure large parts of most emulators are written in a similar way.

 

Still, my point stands that it is very likely that Raspbian is getting in the way of speedy emulation in the case of the RetroPi suite. Theres no reason why a near 1Ghz ARM can't emulate a 1Mhz Apple IIe at speed.

 

If you personally worked on the TI emulation in MESS, I'm certainly not knocking your work. If anything I'm blaming the OS and the driver structure of multi-emulators. You would probably hate what I did to my source copy of MAME. Since I'm only interested in Pre 1990 games, I gutted the drivers and stripped out unneeded processors and hardware to make my own MAME "Lite" for both the Palm OS5 and Mac OS-X. My current binary is only 15MB as opposed to the 100+MB original binary. I can probably get it down to below 10MB when I'm done. It's not about saving space. Gigabytes are cheap. I just like my software "lean and mean" ;)

 

OK I'm going to steer this thread back to TI multi-cart construction by actually attempting to make some progress in the next couple of weeks :P

  • Like 1
Link to comment
Share on other sites

The problem with trying to use that raw processing power when interfaced to the older hardware is that the bottleneck is the older machine's bus which will prevent you from properly taking advantage of that processing power.

Yes, there's a bottleneck, but that does not prevent you from having things done separately on each side of the fence. The TI can send instructions to be performed. It's already happening on a smaller scale with the different carts available (like a write performs a bank switch), and even more so with the F18A as an example.

 

The F18A will be the better RGB output, have much more impressive graphics and finally have 9900 assembler programs execute in the F18A at lightning speed. The bottleneck is in principle still the same few 8 bit VDP ports as we already know them.

 

Here's a few ideas.

 

If you made a write to a certain high address in the 12-bit space, then you could have a special bank with different sets of read and write bytes. Like writing a few bytes there and when the last one is written, have the Pi do some heavy lifting and return bytes in another or much the same area. Maybe resetting the first original write to indicate that the result is ready. Maybe choice of operation in the first byte(s) etc.

 

Wireless access to external files and services (Internet) located on a separate PC/server. Maybe have the Pi render a web page in a 9918A format and feedback a portion.

 

Channel commands to a PC, server or robot to perform whatever.

 

You can more or less directly have the Pi on the cart-port be an even more impressive display (and keep it retro with whatever threshold you want).

 

Of course the Pi at the side-port really opens up the can. I suspect a debugger (with it's own display output) will sit at the side-port more easily.

 

;)

Edited by sometimes99er
Link to comment
Share on other sites

Yes, there's a bottleneck, but that does not prevent you from having things done separately on each side of the fence. The TI can send instructions to be performed. It's already happening on a smaller scale with the different carts available (like a write performs a bank switch), and even more so with the F18A as an example.

 

The F18A will be the better RGB output, have much more impressive graphics and finally have 9900 assembler programs execute in the F18A at lightning speed. The bottleneck is in principle still the same few 8 bit VDP ports as we already know them.

Here's a few ideas.

 

If you made a write to a certain high address in the 12-bit space, then you could have a special bank with different sets of read and write bytes. Like writing a few bytes there and when the last one is written, have the Pi do some heavy lifting and return bytes in another or much the same area. Maybe resetting the first original write to indicate that the result is ready. Maybe choice of operation in the first byte(s) etc.

 

Wireless access to external files and services (Internet) located on a separate PC/server. Maybe have the Pi render a web page in a 9918A format and feedback a portion.

Channel commands to a PC, server or robot to perform whatever.

 

You can more or less directly have the Pi on the cart-port be an even more impressive display (and keep it retro with whatever threshold you want).

 

Of course the Pi at the side-port really opens up the can. I suspect a debugger (with it's own display output) will sit at the side-port more easily.

 

;)

 

 

The F18A is sort of a special case in that it simply takes advantage of the fact that all of the video buffer is in it's domain so that it can process things like scrolling at it's own speed (100Mhz) and send output to alternative displays. The VDP doesn't execute 9900 assembly from what I know, so unless the F18A actually has a full 9900 emulator there will be no assembly speedup there.

 

The bottleneck in the 8-bit VDP port is not just the data width, but the speed at which the console operates (3.xMHz) also. No matter how fast the co-processor is, you will always be limited by the speed at which the TI can feed the data or use the results. That's why I'm asserting that a 100Mhz ARM Cortex-M running bare metal code will be just as efficient as a 1Ghz Raspberry Pi running Linux for any useful application.

 

In the example of wireless web page rendering, I would note that the secondary processor is simply hijacking the console's screen buffer. I would also assert that an LPC1768 M3 could fetch, render, and DMA to the VDP memory just as fast as the display driver would need for equivalent screen refresh rates. For hardware emulation in general, bare metal code or an RTOS will be much better than Linux especially since the TI's hardware timing will need to be adhered to.

 

You're definitely right that the side port would need to be utilized for anything more fun than a multi-cart. My original wish was that I could add the 32K expansion and disk emulation in the multi-cart I'm designing. I really didn't have any intention of putting actual ports in a cartridge save for an SD card slot for disk emulation.

 

If I were to work on any sidecar connected expansion, I would likely use a cortex M3 over a raspberry Pi. An MBED module would make development pretty simple.

 

As it is, my project will be a multi-cart, with room for plenty of both ROM, and GROM images, as well as RAM, in whatever combinations are desired for any existing title as well as new title development, AND live bank switching like Extended Basic does and other carts might do will also be supported, AND carts that do "unnatural" live ROM writes will not mess up a running system as the AVR will be intercepting anything that strobes a write on the address bus as opposed to having the latches directly connected to the ROM bank select lines.

 

I'm actually in progress as I type. I have a TI cart board outline template done in Eagle with the proper fingers for both sides of the board and a schematic symbol with the signal names assigned. I'm choosing Flash and EEProm memory components next.

  • Like 1
Link to comment
Share on other sites

The F18A is sort of a special case in that it simply takes advantage of the fact that all of the video buffer is in it's domain so that it can process things like scrolling at it's own speed (100Mhz) and send output to alternative displays. The VDP doesn't execute 9900 assembly from what I know, so unless the F18A actually has a full 9900 emulator there will be no assembly speedup there.

 

Well, it does. ;)

 

A binary compatible TMS9900-based GPU. This is a full-blown CPU inside the F18A, which basically gives you a 100MHz 9900 as a co-processor with direct access to the VRAM, VDP registers, and a private 2K of RAM above the original 16K of VRAM.

 

http://codehackcreate.com/archives/335

 

 

The bottleneck in the 8-bit VDP port is not just the data width, but the speed at which the console operates (3.xMHz) also.

 

Yes, I know. ;)

 

 

The TI, the cartridge and the cartridge port

A client server architecture.

 

The TI-99/4A is the client sending requests, and the cartridge is the server sending replies. The cartridge port is the connection, the potential bottleneck.

 

 

The power

With the Internet, we’ve seen increase of power in all components. I see the power consisting of mainly computing power, storage power and technical abilities eg. number of colors.

 

The TI has seen increase in power, eg. 32K 16 bit RAM, SAMS, CF7 and F18A.

 

The cartridge has seen increase in power, eg. XB, Mini Memory, SuperCarts, Guidry boards, different color boards and UberGROM.

 

 

The future

There have been steps and leaps in power. Opinions differ and change on what’s sufficient, efficient, breaking and/or pushing barriers too far. I’m here for the nostalgia kick and relaxation.

 

I do appreciate your project. If it works for you, it works. My knowledge of hardware is almost non existing anyway, so there you go. Been thinking big, and doing it small. For now I'm having fun doing 8K ROM cart games in an unexpanded TI-99/4A environment, - and with emulation only. Talk about level and constraints - which may be a keyword with this retro thing.

 

A cart with a RPiZero would also be much more time consuming, with some or a lot of programming on the Pi side. For fun I'm looking into ARM assembly and it's more like 9900 assembly that I could have hoped for. That in itself may be overkill in a wider perspective. And yes, I will be buying that Pi.

 

;)

Edited by sometimes99er
Link to comment
Share on other sites

 

Well, it does. ;)

 

 

http://codehackcreate.com/archives/335

 

 

 

Yes, I know. ;)

 

 

The TI, the cartridge and the cartridge port

A client server architecture.

 

The TI-99/4A is the client sending requests, and the cartridge is the server sending replies. The cartridge port is the connection, the potential bottleneck.

 

 

The power

With the Internet, we’ve seen increase of power in all components. I see the power consisting of mainly computing power, storage power and technical abilities eg. number of colors.

 

The TI has seen increase in power, eg. 32K 16 bit RAM, SAMS, CF7 and F18A.

 

The cartridge has seen increase in power, eg. XB, Mini Memory, SuperCarts, Guidry boards, different color boards and UberGROM.

 

 

The future

There have been steps and leaps in power. Opinions differ and change on what’s sufficient, efficient, breaking and/or pushing barriers too far. I’m here for the nostalgia kick and relaxation.

 

I do appreciate your project. If it works for you, it works. My knowledge of hardware is almost non existing anyway, so there you go. Been thinking big, and doing it small. For now I'm having fun doing 8K ROM cart games in an unexpanded TI-99/4A environment, - and with emulation only. Talk about level and constraints - which may be a keyword with this retro thing.

 

A cart with a RPiZero would also be much more time consuming, with some or a lot of programming on the Pi side. For fun I'm looking into ARM assembly and it's more like 9900 assembly that I could have hoped for. That in itself may be overkill in a wider perspective. And yes, I will be buying that Pi.

 

;)

 

I guess was linked to the initial pages of the F18A project where the scope was just to make a better TMS9918A drop in. Still, having another 9900 on the VDP side while giving faster access to the VDP RAM, still has the bottleneck to the rest of the console. At some point the original TI console is just a dumb terminal to a faster secondary computer regardless of which bus it sits on.

 

I'm with you on the nostalgia kick. That's why I'm happy to just work on a multi cart for the time being. If you're interested in ARM programming that is closer to bare metal, you might want to check out the MBED LPC1768 module. That will get you closer to the hardware than a RPI running linux, but Im not sure if the online MBED compiler will do inline assembly.

 

My cartridge is simply going to be a more capable multi cart in that it will allow a much larger number of GROMs to be present, and will allow any mix of GROM, ROM, and RAM(4K or 8K) that existed in any production or 3rd party cart as well as whatever any new title desired for those resources (Up to certain constraints). It will also allow "live" bank switching for titles that had/need it, while blocking ROM writes for titles that used such methods for apparent copyright protection or just out of bad code. Basically, instead of writing a bank switch select to the address lines, you will write a "Title Select" value and the AVR will take care of selecting the ROM bank, doing or preventing ROM writes or live bank switching, and will emulate the GROM or multiple GROMs for titles that had such.

 

I'm calling my first version of the cart the "AnyCart" as the goal is to be able to provide any cartridge that existed with no restrictions. However, I'm limiting this first version to 128 total titles based on the 512 byte EEPROM in the ATTINY I'm using and the belief that I will need four bytes for each title descriptor that outlines the resources needed for each title. The AnyCart will have a socketed EEPROM and the onboard flash will need to be SPI programmed with some semi-custom programmer. Also the AVR will need to be programmed with an ICE or similar.

 

If I do well with the AnyCarts, I may go on to make an EveryCart, which will have much more space. Theoretically enough to cover 2^12 titles! And everything from the AVR to the GROM Flash to the EEPROM will be able to be programmed over USB either with a flasher program or if I can pull it off, a desktop mounted drag and drop system.

 

The AnyCart is moving along well. I will complete selection of the memory chips and should have a schematic complete in a few days :D I have a ton of embedded and retro projects on a PCB panel, so I hope to add this by the end of the week and send it all off to fab by the Monday after next.

 

You may also be interested in knowing that I have completed the design for a TI Speech ROM (TMS6100) ROMulator module. That project is actually for my 1980s Chrysler voice module custom messages project, but It may also be able to be applied to the TI-99 speech synthesizer. In fact I may use the TI-99 for some of my initial ROM testing! The chrysler module does not use the exact same chip, but I think they both use TMS6100 style ROMs and have compatible LPC encoding parameters.

 

Some of my other Retro projects in flight include Timex Sinclair 1000/ZX81 Composite video boards that ft perfectly into the RF Modulator housing and several Adapters, disk emulators for the Apple II and Macintosh, but discussion of those should be opened on other forums once I get hardware back and tested.

Edited by retro_doog
  • Like 2
Link to comment
Share on other sites

I like this. Keep us in the loop on how you're putting everything together. If you want any testers or help, let me know. Been itching to help out again.. kind of been busy since Fall of 2014 with two moves, but am finally about settled back with my man cave in place.

 

For help with bare metal (before you get the software ready), I can program most chips with my 844USB, so I can likely recover if something goes bad. The programmer also has an ISP port, so if you design the AnyCart that way with some non removable SMT components, I can program those if you put a header in place.

 

Programmer, through ISP connector

  • Serial E(E)PROM: IIC series

  • Microcontrollers Atmel: AT89Sxxx, AT90Sxxxx, ATtiny,

    ATmega series

  • Microcontrollers Cypress: CY8C2xxxx

  • Microcontrollers Elan: EM78Pxxx

  • Microcontrollers EM Microelectronic: 4 and 8 bit series Microcontrollers Microchip PICmicro: PIC10xxx, PIC12xxx,

    PIC16xxx, PIC17xxx, PIC18xxx, dsPIC series Microcontrollers Philips: LPC series
    Notes:

  • (*1) - suitable adapters are available for non-DIL packages

  • (*2) - There exist only few adapters for devices with more than 40 pins. Therefore think please about more powerful programmer (865, 866, 864), if you need to program devices

    with more than 40 pins

Link to comment
Share on other sites

 

I like this. Keep us in the loop on how you're putting everything together. If you want any testers or help, let me know. Been itching to help out again.. kind of been busy since Fall of 2014 with two moves, but am finally about settled back with my man cave in place.

 

For help with bare metal (before you get the software ready), I can program most chips with my 844USB, so I can likely recover if something goes bad. The programmer also has an ISP port, so if you design the AnyCart that way with some non removable SMT components, I can program those if you put a header in place.

 

Programmer, through ISP connector

  • Serial E(E)PROM: IIC series

  • Microcontrollers Atmel: AT89Sxxx, AT90Sxxxx, ATtiny,

    ATmega series

  • Microcontrollers Cypress: CY8C2xxxx

  • Microcontrollers Elan: EM78Pxxx

  • Microcontrollers EM Microelectronic: 4 and 8 bit series Microcontrollers Microchip PICmicro: PIC10xxx, PIC12xxx,

    PIC16xxx, PIC17xxx, PIC18xxx, dsPIC series Microcontrollers Philips: LPC series

    Notes:

  • (*1) - suitable adapters are available for non-DIL packages

  • (*2) - There exist only few adapters for devices with more than 40 pins. Therefore think please about more powerful programmer (865, 866, 864), if you need to program devices

    with more than 40 pins

 

 

Thanks for the offer! Actually, I have a TOP853 programmer for DIP parts and a PLCC socket to DIP adapter board. I also have an Atmel ICE for doing AVRs and I've completed design for a very useful MBED dev platform which will have an expansion SPI/I2C port. I'll use that for programming serial flash over SPI. My end goal is to be able to eventually program over USB via an AtMega with a USB boot loader, but the first prototype will have a PLCC socket for EEPROM(Actual 39F series flash that is pin compatible with the older 28C EEPROMS) and an AtTiny or a non-usb AtMega processor. I'm doing embedded design for a living now, so I have an arsenal of dev tools, programmers, and decent test equipment to aid in my development. Still, it's good to know there are otter resources out there. I may issue a beta cartridge for folks who are willing to do some QA and bug reporting.

Link to comment
Share on other sites

 

Thanks for the offer! Actually, I have a TOP853 programmer for DIP parts and a PLCC socket to DIP adapter board. I also have an Atmel ICE for doing AVRs and I've completed design for a very useful MBED dev platform which will have an expansion SPI/I2C port. I'll use that for programming serial flash over SPI. My end goal is to be able to eventually program over USB via an AtMega with a USB boot loader, but the first prototype will have a PLCC socket for EEPROM(Actual 39F series flash that is pin compatible with the older 28C EEPROMS) and an AtTiny or a non-usb AtMega processor. I'm doing embedded design for a living now, so I have an arsenal of dev tools, programmers, and decent test equipment to aid in my development. Still, it's good to know there are otter resources out there. I may issue a beta cartridge for folks who are willing to do some QA and bug reporting.

 

 

Heh, you and Tursi are like two peas in a pod! Sounds like both of you are embedded gurus.

 

I started the whole cartridge thing probably 7-8 years ago with making simple bank switched ROM carts. People like Matthew with his adaptation with a GAL (not to mention his F18A, which lets new games with new capabilities be on cart), Tursi and Ksarul with adapting the boards into an UberGrom, and now you taking yet another leap... man, that's just awesome. I love this community :) There's too many great people to name them all who have been contributing lately.

 

Be willing to help out or beta test. Love your idea of a database of descriptors of where the files are loaded. So, say you have a 16K bank switched ROM cart, switchable by writing to >6000 and >6002. I'm guessing, that the assets might be somewhere in 16K of the AnyCart flash chip... so you know that if you have XX cartridge, the 16K for it (two banks) are here and here in the flash chip. You select the cart from a menu, and then, you can either intercept the calls via the micro controller and guide it to the right bank on the flash chip, or copy the whole thing to a temporary RAM buffer (read only, like you said), and when you see a write, the micro controller bank switches? Sorry to ask so many questions!

 

Having a DB of what assets are where in flash and remapping them... that makes things extremely portable. Let us know when you have our list of techniques (if you're emulating them) down pat if you don't have them already. For the ROM side, we have bank by writing to ROM, bank by writing to CRU, and inverted banking to ROM (the 8K segments are reversed.) For GROM... there's a whole lot of capability there. 256 bases (I think) x 40K (Groms 3-7) = a little over 10M? ROM likewise can be banked to 32MB, I believe. Lots and lots of space for bulk stuff like sound and animation. But if we actually directly map only the assets we are using, there's no having to mess around with rewriting code, debugging it, and such to get it to work out of a new address space. It'll directly work.

 

I have some of the rarer 32K CRU banked images if you want to borrow them for testing. Michael Zapf with Mess took them and implemented CRU banking in MESS, I believe (which is also used with super carts). I haven't tried running them but will attach them below.

 

So many possibilities here.. :)

DBT Bankswitched.zip

  • Like 1
Link to comment
Share on other sites

 

 

Heh, you and Tursi are like two peas in a pod! Sounds like both of you are embedded gurus.

 

I started the whole cartridge thing probably 7-8 years ago with making simple bank switched ROM carts. People like Matthew with his adaptation with a GAL (not to mention his F18A, which lets new games with new capabilities be on cart), Tursi and Ksarul with adapting the boards into an UberGrom, and now you taking yet another leap... man, that's just awesome. I love this community :) There's too many great people to name them all who have been contributing lately.

 

Be willing to help out or beta test. Love your idea of a database of descriptors of where the files are loaded. So, say you have a 16K bank switched ROM cart, switchable by writing to >6000 and >6002. I'm guessing, that the assets might be somewhere in 16K of the AnyCart flash chip... so you know that if you have XX cartridge, the 16K for it (two banks) are here and here in the flash chip. You select the cart from a menu, and then, you can either intercept the calls via the micro controller and guide it to the right bank on the flash chip, or copy the whole thing to a temporary RAM buffer (read only, like you said), and when you see a write, the micro controller bank switches? Sorry to ask so many questions!

 

Having a DB of what assets are where in flash and remapping them... that makes things extremely portable. Let us know when you have our list of techniques (if you're emulating them) down pat if you don't have them already. For the ROM side, we have bank by writing to ROM, bank by writing to CRU, and inverted banking to ROM (the 8K segments are reversed.) For GROM... there's a whole lot of capability there. 256 bases (I think) x 40K (Groms 3-7) = a little over 10M? ROM likewise can be banked to 32MB, I believe. Lots and lots of space for bulk stuff like sound and animation. But if we actually directly map only the assets we are using, there's no having to mess around with rewriting code, debugging it, and such to get it to work out of a new address space. It'll directly work.

 

I have some of the rarer 32K CRU banked images if you want to borrow them for testing. Michael Zapf with Mess took them and implemented CRU banking in MESS, I believe (which is also used with super carts). I haven't tried running them but will attach them below.

 

So many possibilities here.. :)

 

Hi Acadiel, Thanks for the kind words and ideas! To get things rolling quickly on a prototype, the AnyCart is going to have some limitations. It's goal is to be able to handle most if not all production carts and early 3rd party carts, while being capable of handling many later titles. It really won't be able to easily accommodate new titles with ROMs exceeding 1-4 banks or >40K of GROM in one title. I'm sort of redefining the original latched bank switch scheme into a title selection, but after a title has been selected and launched, the AnyCart will allow titles that had limited bank switching via the writes to >600x to operate based on flags in the descriptor. Titles that did not actually implement bank switching, but instead did writes to ROM either due to bad code, or for copy protection, will have the live bank switching disabled. Oh, and also, SRAM! I'm putting an 8K non-volatile SRAM down that - needs no battery - :D So it will last forever(or at least one million power cycles with a data retention of 100 years). Mini memory should easily be able to be handled by the AnyCart, as well as new titles having a similar option of 4K ROM, 4K SRAM, or live banking of 8-24K ROM + 8K-ish SRAM. The only restriction is that you won't be able to use the lower maybe 256 bytes of the SRAM since writing there might switch the bank. It depends on how deep into address decoding I want to get into. My plan is for the AnyCart hardware to be cheap and easy. It will have 512K of ROM Flash and 512K of GROM flash split into 8K chunks. You will be able to select up to 128 titles, however, unless you were loading the cart with exactly 64 8K ROM only titles plus 64 8K GROM only titles, you probably won't e able to take advantage of the full 128 titles. However, there is a 1Mx8 OTP EPROM that seems to be pin compatible with the socket layout so I will try to have a jumper option to support that chip in case one is willing to give up reflashability for 2x the space. That 1Mx8 is the largest capacity that comes in 5V, and is not a pesky wide TSSOP which makes external programming and socketing a chore(and expensive!).

 

I'm actually still trying to figure out the whole CRU mechanism, let alone using it for bank switching. I just want to "get" what it actually does. I realize it's some sort of serial based device register access as opposed to having memory mapped I/O in the parallel bus space(I think), but beyond that it's still a mystery. This is mostly because I haven't had time to do more than skim the available information on this bus. For me personally, it helps to have background information on WHY TI used this method this and not just how it operates. For the AnyCart, I probably won't have CRU style bank switching in at least for the initial prototype. Hopefully this will not exclude too many titles. I realize my AnyCart really will be an "Almost AnyCart", but that just doesn't roll off the tongue as easily, so I'm just gonna keep calling it the AnyCart ;)

 

My plans for the EveryCart, if I still have the time and resources to develop it in the future, will be to use a much more capable MCU like a 100Mhz Cortex M3. It will utilize a very fast and large unified SPI flash for all resources. The SPI will have to run at at least 33Mhz, I believe, in order to be able to meet ROM timing.The AnyCart's MCU is just a traffic director, intercepting a small number of address and control lines and staying out of the way of the data bus, while generating the appropriate base addresses and chip selects. The EveryCart's MCU is going to have access to the entire slot's signals and all will have to be 5V-3.3V level shifted. Access to everything on the bus, will make it much more powerful. Also, since the processor core will be 32-bits wide and be very fast, complicated math can be done on the address pointers so the memory resources can be utilized much more efficiently. A 6K GROM will only take up 6K, and, if anyone took the time to see how much actual space the carts take up(to the nearest 1K perhaps), we could optimize even further. I would be curious to know even for the AnyCart, if there are a large number of known titles that are actually 4K and under as it wouldn't be too difficult to partition at that granularity.

 

Anyway, after much agonizing over memory chips, and trying my best to shoehorn SPI or SQI onto the AnyCart to make programming easier, I finally realized I'm going to have to start with the good ole 32-PLCC form factor socketed Flash/EEProms for this cart. I wanted a board that I can assemble reasonably easily with my tiny reflow oven and maybe a couple of partial solder stencils, if not solder completely by hand(Through hole and SIOCs). Since the surface mount 32-PLCC sockets are much easier to route, I'll probably be solder pasting and reflowing the AnyCart boards. If this thing really starts to sell, I'll invest in a full board solder stencil or maybe even offload assembly to the PCB fab house. These are going to come in new - repurposed cartridge shells, and I even had a plan to have a special edition that would come in new old stock retail boxes with a printed manual. First things first, though! With component selection complete, I'll be starting the schematic today :D

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...