Jump to content
IGNORED

More cartridge musings


Willsy

Recommended Posts

I didn't want to hijack the 512K cart thread, so I thought I would post this here:

 

 

I actually have a cart, custom built for me by Jens-Eike (it's with him in Germany) that is a 64K bank-switched cart with 1K of ram permanently mapped in to the end of the cart ROM space (so there is 7K or ROM per bank, and the same 1K of RAM in every bank). It also has two hardware stacks on it but there's issues with the stacks - we can do a push (post increment) but pops are proving very tricky (pre-decrement) - something to do with a lack of appropriate signals in the cart port to trigger the pre-decrement, so that might not make it into the final design. We'll have to see. It's a shame because the stacks are lovely: Simply write to an address (I think it's >7FFE) and it pushes that value to the hardware stack. Do a read from the same address and it does a pop! The RAM for the stack is taken from the 1K of RAM. Of course, you don't need to use them if you don't want them, but I want them for a TF V2.x which would have a hardware stack (and thus be faster).

 

It's currently implemented in discrete logic, but I'd be happy to hear to from anyone that is willing to tackle the problem with programmable logic. As I say, there are issues that need to be solved. I spoke with Gary Smith about it here in the UK. He has looked at the problem and agrees that it's a tricky one. He has a tentative solution using flip-flops to induce a delay (if I have understood it correctly) between detecting a read from the stack port (triggering an address decrement) and performing the read.

 

I'd like to get the whole thing into one chip: That is: 64k ROM, 1K RAM and all logic.

 

If anyone is interested is doing a design please let me know. Jens-Eike and Gary has expressed an interest, but it's hard to keep the momentum going - understandable enough... We all have lives outside of the TI

Link to comment
Share on other sites

Yeah, well, it doesn't stop there! It also has (or rather, it *will* have) as SD reader port. It will all fit inside a standard TI cart case. Of course a little slot will have to be cut into the front of the cart case to allow the SD card in and out.

 

The SD reader will be just basic SPI mode - no FAT16 or FAT32 or anything. My intention was to supply the TF firmware on an SD card with the cart. A small amount of firmware in the ROM will, upon wake up, check the firmware files on the SD card. If they are newer, and the checksum is correct, it will just upgrade the ROM/Flash/Whatever in the cart. You can then remove the SD card. I also intended to use the SD card as file/blocks storage for Forth stuff. I was thinking an MSP430 could be used to interface the SD reader with the TI.

 

However, Rome wasn't built in a day... It's pie in the sky at the moment - we're down at the first hurdle - the hardware stacks!

  • Like 1
Link to comment
Share on other sites

In fact, thinking about, the MSP430 *could be* the stacks, too. They have built in RAM... Hmmm....

 

The MPS430 would monitor the appropriate bus lines in the cart and determine when it needs to spring into action (or, external logic could decode the address and MEMEN etc lines, as is done right now and just trigger an interrupt to the MSP 430 with an additional line telling it whether a push or pop is required. The '430 then does its work and (somehow, in the event of a pop) gates the data onto the data bus (maybe until the next clock cycle? I dunno).

 

Hmmm.... That's got me thinking!

Link to comment
Share on other sites

Yes, that's exactly the sort of thing I was thinking. The cart will have some small firmware in it that loads the image from the SD into its ROM/Flash (depends what we end up with).

 

Of course, the stacks (and ram) is selectable. You can turn them off (jumper) so you could have 8K of ROM in all cart banks if you wanted, then you can fill the SD with games! It was only specced at 64K ROM though, since I figured that's all I would need.

 

I have a spec written up for it somewhere. I'll see if I can find it tonight.

Link to comment
Share on other sites

Yes, that's exactly the sort of thing I was thinking. The cart will have some small firmware in it that loads the image from the SD into its ROM/Flash (depends what we end up with).

 

Of course, the stacks (and ram) is selectable. You can turn them off (jumper) so you could have 8K of ROM in all cart banks if you wanted, then you can fill the SD with games! It was only specced at 64K ROM though, since I figured that's all I would need.

 

I have a spec written up for it somewhere. I'll see if I can find it tonight.

 

64K of rom is more than enough I'd say, it's the RAM that matters

Link to comment
Share on other sites

64K of rom is more than enough I'd say, it's the RAM that matters

 

It would be good in certain cases. There are pros and cons, and both are easily debated.

 

Pros:

  • The extra RAM to hold high score counters, buffers, 'working area' (instead of VDP) would speed up some games.
  • No need to buy a Nano PEB to get extra RAM to run a game that needs that working space

 

Cons:

  • When we start doing 4K/4K or 6K/2K boundaries, we lose backward compatibility, and have to start coding on non 8K boundaries (i.e. >6000 to >77FF is ROM only, and >7800->7FFF is RAM). Willsy does mention a switch to disable, above. Essentially, only newly written programs that were written on these boundaries would work properly.
  • Bank switching could be done, but then you lose 2K of each 8K segment unless we really try to fudge and divide into 6K segments (i.e. 64K = 6K x 10) or disable it. Not sure if doing that math is hard or easy.
  • That kind of memory map (split) will only work with that one particular board. Kind of like the proprietary SuperSpace of days of old, except no CRU bank switching. :)
  • RAM is tied to the cartridge; instead of using a Nano PEB or something else for RAM.

With the flexibility that Tursi is building into the AVR with GROM/GRAM and the added ROM, the 512K cart will fill a niche of allowing traditional programs to run, while giving others physical form for the first time (ala RXB, Plant Genetics, Disney cartridges like Peter Pan, Pinocchio, etc.) Most folks will likely be using the 512K cart as a development cartridge (in which case they will already have a Nano PEB, memory expansion, etc), a ROM cart (without the AVR), to give aforementioned software-only cartridges physical form, or as a super-uber-yet-undetermined function. The possibilities are pretty endless, except for the RAM. :)

 

I'd say if we really want to do something cool, we could also make a "super nano PEB" that's just a 32K dongle that fits on the side of the console, so folks don't have to open and modify the system to add 32K to stock systems. It could be super cheap, and I have a prototype in ExpressPCB somewhere if I can find it.

Link to comment
Share on other sites

I'd say if we really want to do something cool, we could also make a "super nano PEB" that's just a 32K dongle that fits on the side of the console, so folks don't have to open and modify the system to add 32K to stock systems. It could be super cheap, and I have a prototype in ExpressPCB somewhere if I can find it.

 

Add an SD card reader/writer on to that (with a DSR to make it look like 3 disk drives to the TI) and you're really at the races!

Link to comment
Share on other sites

I agree with the pros and cons you described. But it all depends on what you are looking for.

What I have in mind is delivering new software (not only games) in cartridge format.

Why cartridge? Kinda weird to explain, but it just feels great to have your software on a cartridge

you can then deliver to people who only have a bare console.

 

Personally I am not interested in putting existing software on a cartridge.

The need for the extra RAM on the cartridge is very important if you want to use another language besides assembler.

The best option for that at this time is probably the C compiler that is currently being targeted for the TI-99/4a.

I love programming asssembly language, but it is very time consuming even when you already have a bunch of subroutines at your disposal.

Also for most people the barrier to get into assembly language is very high.

 

That is why I look in envy to the colecovision scene. Many new homebrew games there, all written in C. That machine has 1K of RAM.

It does not necessarily have to be C. Interpreters/virtual machines could also work and do not necessarily have to be slow.

For fun I looked at the java card virtual machine specification, that would be a geek project. A java card vm running on the ti994a

But the benefit is that you would have an existing language and cross compiler you could use. But it would require a stack, so a bit more than 256 bytes would be great.

Getting carried away now...

 

Link to comment
Share on other sites

That is why I look in envy to the colecovision scene. Many new homebrew games there, all written in C. That machine has 1K of RAM.

 

Yeah, but it actually has some space in it's memory map to where we don't have to cannibalize something else.. :)

 

0x0000 - 0x1FFF BIOS

0x2000 - 0x5fff Unused

0x6000 - 0x7fff RAM

0x8000 - 0x8000 Cartridge ROM

 

I don't remember the missing lines from the cartridge port offhand (but if someone does, please note them below) that are present on the right hand expansion bus, but it keeps us from offering RAM in the full range on the cart port. Someone, please jog my memory....

 

On an unexpanded system, could we slap some RAM in >2000, >4000, and >6000? >6000, definitely, but am not sure about >2000 and >4000. There wouldn't be 32K or DSRs hanging out on an unexpanded system's memory map, after all. :)

Link to comment
Share on other sites

Add an SD card reader/writer on to that (with a DSR to make it look like 3 disk drives to the TI) and you're really at the races!

 

Isn't Jaime working on a new version of the CF7+/NANOPEB that sports an SD card? I think ti99userclub mentioned something.

EDIT: While working on it perhaps SAMS support could be added into the picture as well. :D Guess that could make the device expensive though.

Edited by retroclouds
Link to comment
Share on other sites

Yeah, but it actually has some space in it's memory map to where we don't have to cannibalize something else.. :)

 

(Colecovision) Yeah, but the cartridge port can't use it. :) Those C programs run with the 1k of RAM. I got Mario Bros running in that with bank switching and no extra RAM.

 

I don't remember the missing lines from the cartridge port offhand (but if someone does, please note them below) that are present on the right hand expansion bus, but it keeps us from offering RAM in the full range on the cart port. Someone, please jog my memory....

 

It's impossible to know about access to any CPU addresses besides >6000->7FFF from the cartridge port on the TI. The upper three address lines are not present (and you need that to know which of the 8 blocks of CPU memory are being accessed). A single dedicated line is provided which is pre-decoded for the cartridge memory space instead. I've spent a fair bit of time looking for loopholes.. at this point I still can't think of any. You can know that another memory access is happening, but all you know is it IS >6000->7FFF or it's not.

 

If not for the I/O space, you could use that to do a fakey override and get 16k, but you conflict with the console ROM and I/O space in real life.

 

On an unexpanded system, could we slap some RAM in >2000, >4000, and >6000? >6000, definitely, but am not sure about >2000 and >4000. There wouldn't be 32K or DSRs hanging out on an unexpanded system's memory map, after all. :)

 

On an unexpanded system, you could put RAM at >2000 (normal 8k block for 32k card), >4000 (normally reserved for DSRs to map), >6000 (normal 8k block for cartridge ROM), >A000 (part of 24k block of 32k card), >C000 (part of 24k block of 32k card) and >E000 (part of 24k block of 32k card). You can not put RAM at >8000 because the memory mapped devices own this space (although the block reserved for speech is probably safe). (So, yes.) That means you can technically have 48k of RAM, but only on the side port.

 

Link to comment
Share on other sites

Isn't Jaime working on a new version of the CF7+/NANOPEB that sports an SD card? I think ti99userclub mentioned something.

EDIT: While working on it perhaps SAMS support could be added into the picture as well. :D Guess that could make the device expensive though.

 

RXB has full sAMS support built in so if you have SAMS in the same cart you could take advantage of both with 1 cart.

For those that like using Assembly support in XB this would be a new avenue if you have 32K in the console.

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...