Jump to content
IGNORED

Another abandoned project ?


marc.hull
 Share

Recommended Posts

A couple of weeks a go I was goofing around with PCB express and decided to draw a little Cart schematic with the goal of having a simple off the shelf build with ROM and RAM available. The schematics detail a scheme in which (I hope anyway) this is accomplished.

The cart can utilize an always apparent RAM of 4K as well as 128 4K pages of ROM (or flash RAM in this case.) There is even a battery for saving high scores or other data. The paging scheme is a bit different than in the past. A page is selected by writing it's number to ROM IE a MOVB R0,@>6000 will select page 15 of the ROM (provided R0=>0F00. Additionally this cart always powers up in bank zero (not tested.) The RAM is always on the buss and can be utilized as a small memory expansion.

 

I have lost steam here and don't really see myself pursuing this much more so I am posting the schematics in case someone wants to take off with it or poke holes in it. Either is fine by me ;-).

 

The schematics require PCB Express to read.

cart schem.zip

  • Like 1
Link to comment
Share on other sites

Once I have the layout--we can just do a run of four proto boards to see if they work, it is a relatively cheap test. . .and I have no problems doing that. I'll just send you one to play with :)

 

Sounds good to me. Just be advised that it is all theory right now. Solid I feel but none the less...

Edited by marc.hull
Link to comment
Share on other sites

I feel ya man. I have like 30 or 40 saved projects in GPL I have never finished. Being retired I rotate through them every once in a while.

 

Some of the GPLHOW2s were just old projects I had never finished.

Link to comment
Share on other sites

Okay, for me, 1K in the upper cart memory address would be just fine. Would it be possible to include a jumper for 4K or 1K RAM?

 

(You know, since we're just kicking the tyres here!)

 

Yes It would be possible. Would require some more decoding but would work.

 

The reason I designed it this way though was to have not only RAM and banked ROM but also a large area that was always apparent. Ideal ,in my opinion, to run a small memory manager out of (among other things.) This allows a programmer to store subroutines in banks. When a subroutine is called then that page can be swapped in and the BL made from RAM. When the sub is over then the return is made to RAM where the original calling page is brought back to life and PC restored. It's kind of like a BLWP except you have a page vector and a branch vector

 

Example....

 

Say page 1 wants to call a routine in page 16.....

 

From ROM.....

 

Store existing ROM page# in RAM (1)

Load New ROM page# in RAM (16)

Load branch target in RAM (yyyy)

 

BL to paging routine in RAM

Store R11

switch banks MOVB >0010,@ROM

BL to target address yyyy

 

when routine is over.....

 

B to ram unbanking routine

Restore ROM bank MOVB >0001,@ROM

restore R11

RT

 

This would not be a large amount of code for sure but the rest of RAM could be used for common routines or data storage or whatever gets you going. Since it is always on the buss so to speak then it is available from all ROM pages.

 

Since the cart always starts in bank 1 (hopefully) then that bank would simply download itself to the RAM and go from there.

 

Having never done anything that works from bank switched ROM I can't speak to the advantages or disadvantages to this scheme so you will have to chime in with your thoughts.

Link to comment
Share on other sites

Don't know what direction the cartridge design is going to now. So I guess it doesn't harm to post the below :ponder:

It's basically a rehash of some ideas proposed/discussed with Marc via PM a while ago.

 

1) Would be cool if the amount of available RAM could be configured via a jumper, in say 1K, 2K, 4K.

If you for example have a game that only requires up to 1K of RAM you'd have more ROM space available.

You could make the RAM available from >7FFF upwards to >6000

 

2) Make it possible to disable RAM via software so that the equivalent ROM space is paged in.

The problem when you are working on cartridge software, is that you only have 8K of address space.

If you have to page 4K ROM spaces, you will be doing a lot more bank-switching, which can be a bit of a pain.

 

3) Perhaps add the possibility in the design to go over the 64K ROM boundary (perhaps go up to 128K or 256K).

I don't need to have my graphics in any GROMS. I'd rather store them in ROM banks. Makes life a lot easier.

A game like Prince of Persia would be perfectly possible on the TI-99/4A, you just need some RAM and lots of

ROM space for the graphics.

*** EDIT: This is now included in the current design ***

 

4) Emulator support. That's an important one. At least for me and I guess also for Willsy and his Turboforth.

It would be cool if Tursi could be convinced to add support in classic99.

 

5) Perhaps sell the cartridges as a service (assembled). And with cartridge shell. It would be so cool to have

cartridge shells in different colors (e.g. yellow, red, transparant).

 

6) I really like the idea of programing the cartridge using the TI-99/4A. So I've been thinking if we could also use this feature

for saving high scores, game level status, etc. Allowing you to continue the game where you left off (e.g. for adventure games).

We could write some small assembly routines to support that.

 

7) I've been thinking if this type of cartridge could be used for distributing TI-basic games as well.

Basically you're just copying the BASIC program to VDP memory and run it from there.

Remember the contest made by Owen. I guess there could be an interest in these games.

Immediately increasing the amount of cartridges required and perhaps lowering production costs a little.

 

Would also allow new homebrewers to distribute their TI-Basic games with low costs.

 

8 ) Now I'm getting carried away. What if a single (simulated) GROM could be added to the board. The idea is not to do much GPL programming here.

But to open a gate into the cartridge from TI-Basic. Guess there could be plenty of possibilities, some simple and some more advanced.

*) Add a "CALL LOAD", "CALL PEEK", ...

Perhaps we could reuse a lot of the mini memory code here. I'll get to the CALL LOAD statement shortly.

*) Add a command to trigger the loader

*) Possibility to run your game on a v2.2 console

*) Really advanced: A DSR to save your TI-Basic program in flash.

 

 

9) A loader is required for initially programming the cartridge. How to kick-start the loader? Obviously the flash cartridge must be in the cartridge

port already. Could imagine the below steps:

 

1) Put in Editor/Assembler or Extended Basic and load the loader from disk.

2) The loader attaches itself to the load interrupt.

3) Remove the cartridge and replace with the flash cartridge.

4) Pressing the load interrupt will trigger the loader.

 

At this time I'm not sure how we can swap cartridges without memory being reset? Perhaps by disabling the reset line.

Disadvantage: You need a load interrupt. I have one, but there are plenty of software homebrewers that are hardware noobs like me. If we had (8 ), then we can just load the loader from TI-basic (e.g. Basic program consisting of CALL LOAD statements containing the assembly program)

Link to comment
Share on other sites

On the cartridge case front, I now have a set of case molds. I just have to set up a compressor and pressure pot to use them to make new cases. Black will be easiest to do, but I may get into colors later, as that does require some post curing of the plastic. Setting this up is one of the items on my near-term to-do list.

Link to comment
Share on other sites

Okay, for me, 1K in the upper cart memory address would be just fine. Would it be possible to include a jumper for 4K or 1K RAM?

 

(You know, since we're just kicking the tyres here!)

 

Yes It would be possible. Would require some more decoding but would work.

 

The reason I designed it this way though was to have not only RAM and banked ROM but also a large area that was always apparent. Ideal ,in my opinion, to run a small memory manager out of (among other things.) This allows a programmer to store subroutines in banks. When a subroutine is called then that page can be swapped in and the BL made from RAM. When the sub is over then the return is made to RAM where the original calling page is brought back to life and PC restored. It's kind of like a BLWP except you have a page vector and a branch vector

 

Example....

 

Say page 1 wants to call a routine in page 16.....

 

From ROM.....

 

Store existing ROM page# in RAM (1)

Load New ROM page# in RAM (16)

Load branch target in RAM (yyyy)

 

BL to paging routine in RAM

Store R11

switch banks MOVB >0010,@ROM

BL to target address yyyy

 

when routine is over.....

 

B to ram unbanking routine

Restore ROM bank MOVB >0001,@ROM

restore R11

RT

 

This would not be a large amount of code for sure but the rest of RAM could be used for common routines or data storage or whatever gets you going. Since it is always on the buss so to speak then it is available from all ROM pages.

 

Since the cart always starts in bank 1 (hopefully) then that bank would simply download itself to the RAM and go from there.

 

Having never done anything that works from bank switched ROM I can't speak to the advantages or disadvantages to this scheme so you will have to chime in with your thoughts.

 

 

Marc, the more I think about your suggestion, the more I like it. It's kind of the opposite way around to how I've been doing it, but I like it.

 

In TF there are two 8K banks:

 

Bank 0: Holds the entire Forth dictionary, all words written in Forth (including the interpreter compiler), and common words written in assembly that must run quickly (I.e. I don't want to 'spend' on the time required to do a bank switch), such as all the stack manipulation words and math words.

 

Other words (e.g. sprites etc) have their 'stubs' (i.e their Forth dictionary entries) in Bank 0, but the code just does a:

 BL @BANK1
DATA _SPRITE 

and runs the (assembly) code in bank 1.

 

There is a "bridge" routine in pad ram (i.e. the routine BANK1, above) is in pad ram that actually pages in bank 1, and does a branch to the intended location (_SPRITE in the example above).

 

The code in bank1 calls another routine in pad to page bank 0 back in again, and resume. Both routines are very small.

 

However, I like the idea of just copying a routine in 4K of memory from a bank, and executing it from there. Like you say, commonly used stuff would be copied in at startup and stay there throughout the life of the application. Neat.

Edited by Willsy
Link to comment
Share on other sites

On the cartridge case front, I now have a set of case molds. I just have to set up a compressor and pressure pot to use them to make new cases. Black will be easiest to do, but I may get into colors later, as that does require some post curing of the plastic. Setting this up is one of the items on my near-term to-do list.

 

I personally would *love* translucent cases. Not transparent, but translucent! I had the idea of having two LEDs in the TF cart, one red, one green, and giving the user access to these:

 

1 GLED ( turn green led on)

0 GLED ( turn it off)

 

1 RLED ( turn red led on)

0 RLED ( turn it off)

 

If the user generated an error when typing in code, the red led would turn on, etc, so the whole cart would glow red!

 

Love it!

 

Can we have LEDs in the design please? PLEASE?

Link to comment
Share on other sites

Looking at Marcs logic diagrams, could the discretes not all be mopped up into a single programmable chip? Back when I was active in such things, we had chips called PALs and GALs - these were tiny, say, 12 or 16 pin DIL chips and you could program (and re-program) them with your own logic. We used a neat little program called PALASM to program the chips. You just used boolean logic equations. It was very simple and did the job perfectly.

 

/CS = PIN 9 ; chip select will be on pin 9, true will be a low

 

/CS = (A1 + A2 + A3) * MEMEN ; /CS=(a1 OR a2 OR a3) AND MEMEN

 

Something like that. Does anything with this level of "simplicity" still exist? Or are they all massive big hairy FPGAs for building your own floating point processor? ;)

Link to comment
Share on other sites

/CS = PIN 9 ; chip select will be on pin 9, true will be a low

 

/CS = (A1 + A2 + A3) * MEMEN ; /CS=(a1 OR a2 OR a3) AND MEMEN

 

[pedantry]

Actually, I don't *think* it was clever. If you wanted active low, then you would do something like:

 

CS = PIN 9 ;

CS = NOT((A1 + A2 + A3) * MEMEN) ;

 

But you get the idea ;)

[/pedantry]

Link to comment
Share on other sites

Looking at Marcs logic diagrams, could the discretes not all be mopped up into a single programmable chip? Back when I was active in such things, we had chips called PALs and GALs - these were tiny, say, 12 or 16 pin DIL chips and you could program (and re-program) them with your own logic. We used a neat little program called PALASM to program the chips. You just used boolean logic equations. It was very simple and did the job perfectly.

 

/CS = PIN 9 ; chip select will be on pin 9, true will be a low

 

/CS = (A1 + A2 + A3) * MEMEN ; /CS=(a1 OR a2 OR a3) AND MEMEN

 

Something like that. Does anything with this level of "simplicity" still exist? Or are they all massive big hairy FPGAs for building your own floating point processor? ;)

 

 

TI still makes and sells one time PALS but they are all in the 3V range AFAIK. Adding a PAL would probably require that the signals be buffered though. PALS tend to be pretty fragile in my experience. I would think a FPGA would be better and we have a resident expert on list ;-).

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

  • Recently Browsing   0 members

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