Bouncing Babies

[Tursi]

The way it works is like this...

 

An EPROM is a standard ROM chip that you probably already understand, but I'll go into detail so the differences are more clear. An EPROM has a set of input pins called the address bus, and a set of output pins called the data bus (ignoring the programming phase - my description only covers reading it in the cartridge port.) The address bus size depends on the size of the EPROM, but at the cartridge port it has a range of 8k. The data bus at the cartridge port is always 8 bits wide.

 

When the TI wants a byte of data from the EPROM, you simply do an assembly instruction that reads memory, for example, MOV @>6000,R0 will move the first 2 bytes from a cartridge EPROM into register 0. At the hardware level, the console first determines where >6000 is. Discovering it is at the cartridge port, it strips off the high bits, sends the address >0000 to the cartridge port, and triggers the cartridge selection pin. The EPROM sees the select, sees the address >0000, and puts the first byte on the data bus. The console reads the data from the data bus, then repeats the process with >6001. Once the console has both bytes, it copies the result into R0 and the program continues. Note that ROMs and EPROMs work the same way from this point of view, the only difference is one is externally programmable (which I won't go into detail on). EPROMs are used in thousands of machines and EPROM programmers are very common and easy to come by (and they come in almost every configuration you can dream of, but 8-bit wide EPROMs are most useful to us on the TI).

 

GROMs work very differently. GROMs have just a single data bus, and two control pins. The data bus is 8 bits wide, just like in the EPROMs. One control pin specifies whether you are dealing with DATA or ADDRESS, and the other controls whether you are READING or WRITING. Although any combination is possible, GROMs will ignore the combination WRITING DATA, everything else is valid. TI GROMs (I won't discuss clones, GRAM devices, or other such) contain 6k of data each. In order to manage 6k of data through a single 8-bit port, they have their own internal address counter, which you set by using the WRITING ADDRESS combination. Once it is set, every READING DATA operation automatically adds one to the internal address, so that you can just keep reading without having to set it every time.

 

This makes accessing the GROMs more work, because you have two limitations. First, you have to explicitly tell the chip what address you want, and second, the automatic system in the console for turning bytes into words of two bytes won't work on them. Without going into too much detail, the GROMs are accessed as if they were devices, like the video chip, by reading and writing to special reserved addresses on the REAL address bus. So to duplicate the case of getting two bytes from >6000 in the GROM space, the code looks more like this:

 

  LI R1,>6000  * copy the address we want into a register
 SWPB R1      * send the lowest address byte first
 MOVB R1,@GRMWA  * write the first byte to write address - this sets the WRITING ADDRESS pins on the GROM
 SWPB R1      * get the other byte ready
 MOVB R1,@GRMWA  * write the second byte to write address - now the address is loaded in the GROM chip
 MOVB @GRMRD,R0  * get the first byte of data, this address sets the READING DATA pins on the GROM
 SWPB R0      * prepare the register
 MOVB @GRMRD,R0  * get the second byte of data from the GROM
 SWPB R0      * put them back in the right order

 

Not only is it that much more complicated, but GROMs are also much slower than EPROMs, because of all the address work they do internally. While EPROMs are fast enough to respond to the console in normal memory times (easily!), GROMs actually have to halt the CPU while they work, and a single access can take 3-4 times longer than an EPROM access. (A GROM made with modern electronics would easily be fast enough, but the console GROMs will still enforce the slow access as they can't be disabled).

 

GROMs work similarly to modern "serial EEPROM" devices, but the problem is that they are 8-bits wide and use a different control mechanism, so there's really no modern equivalent we can drop in. In addition, EPROMs are faster to respond, easier to work with, allow faster code, and can run assembly language (GROMs can not because of the way they work, at best they can run interpreted GPL). The GROM sole advantage was that they allowed 40k of data at the cartridge port, while EPROMs were limited to 8k, but with simple bank switching hardware like Jon's design it is trivial to expand EPROMs far beyond 40k, removing even that advantage.

 

The only reason my converter outputs GROM instead of ROM images, was because I wanted to give people a simple way to distribute their games for emulation, and the larger size of GROM was idea (especially since no emulators supported a standard EPROM bank switch scheme). But I will change that when I get some time! Also, the only reason I'm working on a real GROM simulator is I want to use the GROM port to access SD devices for gigabytes of data, without conflicting with the ROM port, and also to provide a way to reproduce older, useful carts like Editor/Assembler, should we ever need to.

[jchase1970]

great answer Tursi that explains alot that I didn't know about the hardware.

 

John

[Mad Hatter]

Hmm so this file (BBABY) works fine for me in Classic99, however on the actual equipment I get an I/O ERROR 2 when I try to load it using either the OLD or RUN commands. Any ideas? I have tried the transfer 3 times with the same results, and have tried using different disks as well.

[Tursi]

Hmm so this file (BBABY) works fine for me in Classic99, however on the actual equipment I get an I/O ERROR 2 when I try to load it using either the OLD or RUN commands. Any ideas? I have tried the transfer 3 times with the same results, and have tried using different disks as well.

 

Error 2 (is it 02?) looks like it means bad attribute, which might mean the file type is wrong. My PEB isn't hooked up, can someone else try?

[jchase1970]

Hmm so this file (BBABY) works fine for me in Classic99, however on the actual equipment I get an I/O ERROR 2 when I try to load it using either the OLD or RUN commands. Any ideas? I have tried the transfer 3 times with the same results, and have tried using different disks as well.

 

 

Hmm, you can't even load it with OLD? Sounds like a bad file copy. You do have the Extend Basic cart in right?

[Mad Hatter]

Yeah, I transferred the exact same file that works on Classic99 over to the TI. I transferred it 3 different times and used two different disks.. just to make sure the disk wasnt the problem. Same results each time. And yes I am using Extended Basic.

 

Hmm so this file (BBABY) works fine for me in Classic99, however on the actual equipment I get an I/O ERROR 2 when I try to load it using either the OLD or RUN commands. Any ideas? I have tried the transfer 3 times with the same results, and have tried using different disks as well.

 

 

Hmm, you can't even load it with OLD? Sounds like a bad file copy. You do have the Extend Basic cart in right?

[UnderExtended]

I made a cart image that plays fine in win99.

 

John, can you post the Win99 cart version please? I just don't have Classic 99 yet.

 

I have been able to convert a few things to work in Win99, but when I loaded your file in TI-Dir, all I got from the size 49 file was: 10 CALL INIT :: CALL LOAD(8192,207,058) :: CALL LINK("RUN")

 

--Rich

[jchase1970]

Yeah rich I had the same problem with win99 and transfering the file, which is why I made the cart.

 

You will have to use the create new cart function I believe,

this is the GROM file

 

BOUNCING.bin

 

I created a cart for the win994a and I have it in my cart list but I can't find the physical .TICart file any where.

[jchase1970]

Yeah, I transferred the exact same file that works on Classic99 over to the TI. I transferred it 3 different times and used two different disks.. just to make sure the disk wasnt the problem. Same results each time. And yes I am using Extended Basic.

 

Hmm so this file (BBABY) works fine for me in Classic99, however on the actual equipment I get an I/O ERROR 2 when I try to load it using either the OLD or RUN commands. Any ideas? I have tried the transfer 3 times with the same results, and have tried using different disks as well.

 

 

Hmm, you can't even load it with OLD? Sounds like a bad file copy. You do have the Extend Basic cart in right?

Have you every downloaded a XB autoload file from TIGAMESHELF.NET and transfered it? I wonder if that is the problem.

 

If you have EA here is the EA5 files for it.

 

BABY5.zip

Edited July 12, 2010 by jchase1970

[UnderExtended]

You will have to use the create new cart function I believe,

this is the GROM file

 

Cool, thanks!

 

--Rich

[+retroclouds]

Yeah, I transferred the exact same file that works on Classic99 over to the TI. I transferred it 3 different times and used two different disks.. just to make sure the disk wasnt the problem. Same results each time. And yes I am using Extended Basic.

 

Hmm so this file (BBABY) works fine for me in Classic99, however on the actual equipment I get an I/O ERROR 2 when I try to load it using either the OLD or RUN commands. Any ideas? I have tried the transfer 3 times with the same results, and have tried using different disks as well.

 

 

Hmm, you can't even load it with OLD? Sounds like a bad file copy. You do have the Extend Basic cart in right?

Have you every downloaded a XB autoload file from TIGAMESHELF.NET and transfered it? I wonder if that is the problem.

 

If you have EA here is the EA5 file for it.

 

 

 

 

When I tried to load BABY5 using #EA5, I get an error "07".

It seems it's also trying to load BABY6 ?

[jchase1970]

Yeah, I transferred the exact same file that works on Classic99 over to the TI. I transferred it 3 different times and used two different disks.. just to make sure the disk wasnt the problem. Same results each time. And yes I am using Extended Basic.

 

Hmm so this file (BBABY) works fine for me in Classic99, however on the actual equipment I get an I/O ERROR 2 when I try to load it using either the OLD or RUN commands. Any ideas? I have tried the transfer 3 times with the same results, and have tried using different disks as well.

 

 

Hmm, you can't even load it with OLD? Sounds like a bad file copy. You do have the Extend Basic cart in right?

Sorry, file added

Have you every downloaded a XB autoload file from TIGAMESHELF.NET and transfered it? I wonder if that is the problem.

 

If you have EA here is the EA5 file for it.

 

 

 

 

When I tried to load BABY5 using #EA5, I get an error "07".

It seems it's also trying to load BABY6 ?

[Opry99er]

Curious problem here... I have found that TI Puck transfers and works great on the real gear... Also uses Wilhelm's compiler...

 

You know, TI BASIC programs can be put onto cartridge. =) Without being compiled. The only reason XB programs cannot is that they require the cartridge port for the XB GROMS and ROMs. I'd like to see a few TI BASIC games on cart... Would be kinda cool.

 

A question for you jchase.... Once you compiled your TI BASIC program, was it too fast? Did you end up having to use delay loops to make it manageable?

[Opry99er]

The way it works is like this...

 

An EPROM is a standard ROM chip that you probably already understand, but I'll go into detail so the differences are more clear. An EPROM has...

.

.

.

 

What an excellent explanation of this!!!! Saving this into "the folder." Thanks alot!

[jchase1970]

Yeah, I transferred the exact same file that works on Classic99 over to the TI. I transferred it 3 different times and used two different disks.. just to make sure the disk wasnt the problem. Same results each time. And yes I am using Extended Basic.

 

Hmm so this file (BBABY) works fine for me in Classic99, however on the actual equipment I get an I/O ERROR 2 when I try to load it using either the OLD or RUN commands. Any ideas? I have tried the transfer 3 times with the same results, and have tried using different disks as well.

 

 

Hmm, you can't even load it with OLD? Sounds like a bad file copy. You do have the Extend Basic cart in right?

 

 

OK, New file for you to try. This version was compiled in win994a. I have a feeling it will work for you. I had the same problem trying to send the XB Autoload file from classic99 to WIN994a.

 

This disk file create in WIN994a runs the program in WIN994a.

Please post if it works like expected, if it does there is a problem with classic99.

 

Bouncing babies.zip

[jchase1970]

Curious problem here... I have found that TI Puck transfers and works great on the real gear... Also uses Wilhelm's compiler...

 

You know, TI BASIC programs can be put onto cartridge. =) Without being compiled. The only reason XB programs cannot is that they require the cartridge port for the XB GROMS and ROMs. I'd like to see a few TI BASIC games on cart... Would be kinda cool.

 

A question for you jchase.... Once you compiled your TI BASIC program, was it too fast? Did you end up having to use delay loops to make it manageable?

 

No, delay as in total system stop delay. Here's how it works.

 

I have a inc counter

When it reaches a setpoint it resets and moves the babies

The keyboard input is not loop dependent so you have keyboard control with no delay effect.

 

 

This is how to slow a games action with out effecting the controlability.

If you just throw in a delay like this,

for delay=1 to 100::next delay

move baies

call key

 

then you risk missing key strokes during the delay loop

 

 

owen please have you also tried to load this on the original machine? If so please use the file I just posted for mad hatter and see if it works for you.

[+retroclouds]

This is what the classic99 debugger shows when trying to load via #EA5.

 

 

I'd really love to try the #EA5 version. Is there a baby6 file missing ?

[Opry99er]

I have not tried it on hardware... I will try to slap it into the CF7 and give er a go. I haven't been doing many serial transfers lately--- the CF7 is just so darn easy! I don't know if I can get to this today--- but I'll try to hit it up this week sometime. Busy busy busy. . My hardware setup is at my sister's place--- in the basement. I get over there once or twice a week.

[Mad Hatter]

The new file is too big for me to transfer (360k). I have a DSSD drive so 180k is my max.

 

 

 

Yeah, I transferred the exact same file that works on Classic99 over to the TI. I transferred it 3 different times and used two different disks.. just to make sure the disk wasnt the problem. Same results each time. And yes I am using Extended Basic.

 

Hmm so this file (BBABY) works fine for me in Classic99, however on the actual equipment I get an I/O ERROR 2 when I try to load it using either the OLD or RUN commands. Any ideas? I have tried the transfer 3 times with the same results, and have tried using different disks as well.

 

 

Hmm, you can't even load it with OLD? Sounds like a bad file copy. You do have the Extend Basic cart in right?

 

 

OK, New file for you to try. This version was compiled in win994a. I have a feeling it will work for you. I had the same problem trying to send the XB Autoload file from classic99 to WIN994a.

 

This disk file create in WIN994a runs the program in WIN994a.

Please post if it works like expected, if it does there is a problem with classic99.

 

Bouncing babies.zip

[jchase1970]

This is what the classic99 debugger shows when trying to load via #EA5.

 

 

I'd really love to try the #EA5 version. Is there a baby6 file missing ?

 

Retroclouds I added baby6 file in the baby5 zip DL. SO redownload it and give it a try.

[jchase1970]

The new file is too big for me to transfer (360k). I have a DSSD drive so 180k is my max.

 

 

 

Yeah, I transferred the exact same file that works on Classic99 over to the TI. I transferred it 3 different times and used two different disks.. just to make sure the disk wasnt the problem. Same results each time. And yes I am using Extended Basic.

 

Hmm so this file (BBABY) works fine for me in Classic99, however on the actual equipment I get an I/O ERROR 2 when I try to load it using either the OLD or RUN commands. Any ideas? I have tried the transfer 3 times with the same results, and have tried using different disks as well.

 

 

Hmm, you can't even load it with OLD? Sounds like a bad file copy. You do have the Extend Basic cart in right?

 

 

OK, New file for you to try. This version was compiled in win994a. I have a feeling it will work for you. I had the same problem trying to send the XB Autoload file from classic99 to WIN994a.

 

This disk file create in WIN994a runs the program in WIN994a.

Please post if it works like expected, if it does there is a problem with classic99.

 

Bouncing babies.zip

 

 

Yeah, I made a disk image of a DSDD disk that only has 1 file on it, so can you just pull the file out of the disk image using ti99dir. Let me know what happens.

 

Thanks for hanging in there with me on this, I don't have a disk drive or anyway to get my files from the PC to the TI, so it's great to have people to work with. This is also a learning process and I'm not sure why the original file compiled in the classic99 emulator wont transfer over. But since I can duplicate the error when trying to get it to play in win994a, make me wonder if it's classic99 causing the problem, or ti99dir causing the problem.

 

Tursi if you are reading this,

 

I take the basic saved file BABY and use ti99dir and send it to a disk image and it plays on win994a.

 

But when I send the XB-autoload file, win994a wont load it in, as hatter said not RUN or OLD commands.

 

I can take the basic file in win994a and use the compiler and it compiles fine and now plays in win994a.

 

I can then take the xb-autoload file and copy it to my dsk1 folder, using ti99dir, for classic99 and it will play on classic99.

 

seems like classic99 is not doing something right when saving the xb-autoload file?

 

John

Edited July 12, 2010 by jchase1970

[Opry99er]

Hey John--- I did a speed test video for my Opry99er YouTube channel comparing a very slow XB program to it's compiled equivalent. My idea was to show it working in emulation and then on the real hardware... Now that you mention it, I remember that it would NOT run on my console.... I didn't have time to trouble-shoot and there were very few people interested in my efforts with the compiler, so I just posted the Classic99 video and never re-visited it... I don't have any knowledge as to "why" it didn't work, but I just let it go--- I had other matters to attend to. The speed test video is still on my channel--- I used Wilhelm's compiler to do it and it was super fast!

[jchase1970]

Hey John--- I did a speed test video for my Opry99er YouTube channel comparing a very slow XB program to it's compiled equivalent. My idea was to show it working in emulation and then on the real hardware... Now that you mention it, I remember that it would NOT run on my console.... I didn't have time to trouble-shoot and there were very few people interested in my efforts with the compiler, so I just posted the Classic99 video and never re-visited it... I don't have any knowledge as to "why" it didn't work, but I just let it go--- I had other matters to attend to. The speed test video is still on my channel--- I used Wilhelm's compiler to do it and it was super fast!

well, I'm really thinking its a bug in c99, we will find out as soon as someone trys to copy the new file i posted in the reply for mad hatter. This is where some extra gear would be really handy,

[Mad Hatter]

Ok, I just tried the new file. When I try to autoload the program (with the LOAD file), the disk drive runs, then it just goes to the X/B main screen with the *READY* prompt. When I try to manually load it using the OLD or RUN commands I still get that same I/O error msg.

 

well, I'm really thinking its a bug in c99, we will find out as soon as someone trys to copy the new file i posted in the reply for mad hatter. This is where some extra gear would be really handy,

[jchase1970]

Ok, I just tried the new file. When I try to autoload the program (with the LOAD file), the disk drive runs, then it just goes to the X/B main screen with the *READY* prompt. When I try to manually load it using the OLD or RUN commands I still get that same I/O error msg.

 

well, I'm really thinking its a bug in c99, we will find out as soon as someone trys to copy the new file i posted in the reply for mad hatter. This is where some extra gear would be really handy,

 

 

OK, That helps. It's not enough memory, With the new file if I load it in win994a with 32k it works and when I load it with out 32k it does the same thing for me and I get IO error 57. I think I can fix this, will have to edit something and make another compile of it if this is it.

 

Do you have a 32k card?

 

 

Will check back later, painting a bedroom - ohh what fun.