First steps in TI9900 assembly language with prior knowledge of 6502

[Tursi]

Also, the P-Code card doesn't use the normal GROM addresses at all -- instead it creates a GROM 'base' inside the DSR space when the card is switched on.

Edited April 5, 2015 by Tursi

[Tursi]

So the other 240 bases are usable, but won’t be detected by the OS, are only available on the I/O port, and are not available on the UberGROM cart / AVR?

 

To be clear, the "OS" in this case is just the boot menu, nothing else in the console really cares about cartridge GROM layout. The UberGROM only decodes 16 bases as a compromise between I/O pins in use and available memory - it only has 120k available anyway, and that already gives far more slots than available devices, so there was no value going further.

Edited April 5, 2015 by Tursi

[Dexter]

Just a random thought, since we’re OT already

On my Single Board Computer MARC-2, there is no ROM, there is only SRAM throughout the whole address range, except for the I/O at BF00-BFFF. There is an ATmega1284P connected to the SRAM’s address, data and control lines. During startup / reset, the AVR fills the region of C000-FFFF with the firmware. After reset, the AVR becomes tri-stated, and the range C000-FFFF is write protected and acts as if it were “ROM”. This way I can develop on the firmware on the fly.

 

My idea would be to replace the FLASH ROM by an SRAM on the UberGROM cart. Then it would be a completely universal cartridge.

 

The code for filling the SRAM is written in AVR assembly, and takes the ROM image out of the AVR’s flash memory.

 

However, that might be something for a separate thread. Just wanted to share the idea.

Edited April 5, 2015 by Dexter

[Gazoo]

My idea would be to replace the FLASH ROM by an SRAM on the UberGROM cart. Then it would be a completely universal cartridge.

 

The code for filling the SRAM is written in AVR assembly, and takes the ROM image out of the AVR’s flash memory.

 

 

Several questions. How would you prevent the SRAM from bank switching when you were writing to it? Do you have a way to lock the 378?

 

The AVR's flash memory is 128k, and the SRAM would be 512k. You're only going to use 128k (or less) of the SRAM? And eliminate the Grom emulation?

 

I'm not sure how this makes the cart 'universal'.

 

Gazoo

[+Ksarul]

Point taken on the Cartridge space, Tursi. I was speaking from the standpoint of what the OS checks, not from the standpoint of what the hardware is capable of--for both systems. The 99/8 is using two full sets of 8 GROMs inside the console and separate from the cartridge port (Extended BASIC II and p-System), selectable through the initial menu. I will have to look at the documentation again to see which GROM base each one uses. It definitely uses GROM in the same way as a /4A does.

[Dexter]

In my view, most cartridges are 8KiB ROM and max. 5 GROM’s. So that would be without an LS378. This assumption of course might be incorrect. My knowledge of the existing cartridges is almost non existing.

 

I’m actually thinking more of a SuperCart, which has 8K of RAM (without banking). Any GROM’s could be simulated by the AVR. The ATmega1284P has too few pins to simulated the GROM’s and connect to all pins of the SRAM. One solution could be the use of an Arduino MEGA board. Software for the GROMS’s and SRAM could be provided by one of the serial ports of the MEGA, and connected to the PC through a USB <–> TTL Serial bridge. It also might be nesecary to disconnect the SRAM with ‘245’s for programming it.

 

In essence, it would be a super cart with the E/A GROM replaced by an AVR, programmable through a serial connection to the PC.

 

And then again, does such a variation has any value at all, given that almost every cartridge is available on those big cart collections?

 

 

 

 

[Omega-TI]

 

In essence, it would be a super cart with the E/A GROM replaced by an AVR, programmable through a serial connection to the PC.

 

And then again, does such a variation has any value at all, given that almost every cartridge is available on those big cart collections?

 

 

YES, at least IMHO. You are channeling my dreams here.

My hope is that someday we will have a Uber/Super Cart.

 

Why? Because my dream is:

 

Turning on the computer and instead of a title screen or a menu screen, have 4A/DOS loaded and automatically searching for a BATCH file or if none is present, drop to the command prompt. This would give the user awesome customization capabilities, while retaining the massive utility of this Uber Cart, because it the user held down a button while turning it on, it would bypass the 4A/DOS routine and go directly to a menu where one would have some major utilities like DM2K, DSK2PC and of course the E/A cartridge and of course XB 2.7.

 

I have always wanted a DOS environment for the TI, I loved it on the TRS-80 and the PC as well.

[+Ksarul]

On cartridges originally designed for the TI, there are a few that use up to four banks of ROM (mostly from DataBioTics, but at least one is also from TI). All of the various flavors of Extended BASIC use at least two banks (one, XB3, uses three), as do a lot of third-party cartridges (two banks). Note that all of these are ROM requirements. The TI cartridges (and the various flavors of XB) also use the GROM space (though not all of them use all five available GROM slots).

[Dexter]

And how do those cartridges switch ROM banks? By programming and addition logic on that cartridge?

 

edit

Like the 378 on the UberGROM cartridge.

/edit

Edited April 5, 2015 by Dexter

[+Ksarul]

They use external ICs to respond on a bank switch command (a write to >6000, >6002, >6004, etc.) in the case of TI cartridges, in the case of DBT cartridges, they used a write to a CRU address to do the same.

[+Lee Stewart]

@Willsy's TurboForth is a 2-bank, ROM-only cartridge and my fbForth 2.0 is a 4-bank, ROM-only cartridge—no GROM in either.

 

...lee

[+Ksarul]

Don't forget Pitfall!, as that one is also a multi-bank cartridge (4) that runs purely in cartridge space.

[Dexter]

 

YES, at least IMHO. You are channeling my dreams here.

My hope is that someday we will have a Uber/Super Cart.

 

Well what I was suggesting is i.e. nothing more than a variation of the UberGROM cartridge. What would be different is the provision of the software to the cart. That could be serial to PC or an SD-cart with a menu system.

 

However, seen the only software I know which exploits the capabilities of the UberGROM cartridge is the XB 2.7 Cartridge Suite. I’m not sure if there is more, which uses GROM's.

 

 

When my Supercart PCB arrives, I’ll to get it working with an ATmega1284P instead of an E/A GROM. First I’ll try this version of the E/A GROM from Tursi. I’d be very happy if it works, but I think that should.

 

 

 

Anyway, it’s too early for me now to know how those more sophisticated multibank cartridges work. First learning some Assembly Language and try to make a simple program start as a cartridge. One step at a time...

[Tursi]

However, seen the only software I know which exploits the capabilities of the UberGROM cartridge is the XB 2.7 Cartridge Suite. I’m not sure if there is more, which uses GROM's.

 

Well, yes, but we only released it like a month or so ago, give people time.

[Dexter]

 

Well, yes, but we only released it like a month or so ago, give people time.

Hihi, I have the excuse of ignorance. Does that count?

[Dexter]

Hi Matthew,

 

I’m studying your “Assembly on the 99/4A” thread. Thank you for creating such a marvelous tutorial and skeleton file. I’m itching to put something together what perhaps might looks like a game. I’m very thrilled about your universal VDP routines, and that you don’t use the console ones.

 

I’ve got a few questions, but first I’d like to setup the tool chain to a maximum of comfort.

 

I noticed you’re also using Textpad as your favorite editor.

http://atariage.com/forums/topic/204157-file-format-in-classic-99/?p=2620164

Would you like to share that config file you made for Textpad, to create those nice looking source codes?

 

Marco

Edited April 10, 2015 by Dexter

[Dexter]

Sorry, if I had read to the end of the thread, I didn’t have to ask.

Who can read, clearly has the advantage.

 

Next question, I can’t seem to find a help file or manual for the WinAsm99 assembler section. Is that because it’s completely conform to the Editor / Assembler rules, so I can stick to that manual?

[Asmusr]

I think the attached is all there is. And yes, it is a standard assembler with a few enhancements (e.g. longer labels allowed). You can also do conditional assembly using IF/ELSE/ENDIF.

 

BTW, statistics speak in your favor if you follow Matthew's guidance. I think close to 100% of the assembly games that have been released in the last two years have been based on his methods.

Getting Started.txt

[matthew180]

@Dexter: I'm glad you find the information useful. I have been using Textpad since the 90's and use it almost exclusively for 9900 assembly, although these days I long for an assembly editor that has some intellisense. I have stopped using the TI Editor/Assembler (you will see that abbreviated EA) tab-stops though, since win99asm supports long labels and most people just use 4-space tabs.

 

I think I should probably revisit some of the code in that thread since I have evolved some things since that was written. The console's VDP routines (and most other console routines) were designed for space efficiency, mine were designed for speed. There is always a trade-off. I also like to understand everything and the console VDP routines were always a black-box to me, so it was one of the first things I tackled when I got back into the TI after a decade hiatus. The keyboard is another, and I plan to write a generic keyboard handling module that is more efficient and easy to use (I hate dealing with the keyboard.)

 

I have also modified my opinion on the whole polling vs interrupt debate, so I feel I should update that information and give examples of the three methods so people can decide which they want to use.

 

As for win99asm, like Rasmus said, there is little to no documentation on the enhancements it has. We know you can use longer labels, and apparently conditional compiling (which I did not know until just now). It does have some nuances when using BYTE though, so you have to be careful where your labels end up pointing. Writing an assembler has been on my todo list for a long time, but I guess the pain threshold of existing tools has not been high enough to move that project to the top of the list (and oh what a long list it is.)

 

If you have questions please ask. Don't worry about posting in, and resurrecting, an old thread - that's what threads are for.

 

@Rasmus: Much appreciated testimony.

[Dexter]

@Rasmus-M

 

I think the attached is all there is. And yes, it is a standard assembler with a few enhancements (e.g. longer labels allowed). You can also do conditional assembly using IF/ELSE/ENDIF.

 

That’s good to know, then I can refer to all the books and the user manual from the EA itself without exception.

 

 

BTW, statistics speak in your favor if you follow Matthew's guidance. I think close to 100% of the assembly games that have been released in the last two years have been based on his methods.

 

I actually know of four games which fit that criteria:

· Road Hunter

· TI Scramble

· Titanium

· Flappy Bird

However, I think I’m neglecting a lot of other games and programmers!?

 

@matthew180

 

I have been using Textpad since the 90's and use it almost exclusively for 9900 assembly

 

I’ve also been using the free version 5.2.4 for a long time for the ACME Cross-Assembler http://sourceforge.net/projects/acme-crossass/

 

 

The console's VDP routines (and most other console routines) were designed for space efficiency, mine were designed for speed. There is always a trade-off. I also like to understand everything and the console VDP routines were always a black-box to me, so it was one of the first things I tackled when I got back into the TI after a decade hiatus.

 

Yes, I also think that speed is of more importance to us these days. Probably everyone who uses a TI-99/4A today, has a 32KiB RAM expansion. For me, fast universal VDP routines are even more important, as I want to use the F18A in both, the 4A, and my 65816 homebrew computer MARC-2. If I manage to program anything, I’d like to do that for the both of them. In the future, I’d also like the SID (6581) in my 4A, but that’s on a familiar list.

 

 

The keyboard is another, and I plan to write a generic keyboard handling module that is more efficient and easy to use (I hate dealing with the keyboard.)

 

I definitely would like that, as I understand, debouncing is an issue here. Instead of a delay, one could also use a “confidence counter” to address debouncing. Meaning, when reading the same logical level of a key for x times, one can be confident that that level has been stabilized. Poorly explained, but here is an AVR video about it.https://www.youtube.com/watch?v=sSOz1QcYnB0&list=PLE72E4CFE73BD1DE1&index=14

 

 

I have also modified my opinion on the whole polling vs interrupt debate, so I feel I should update that information and give examples of the three methods so people can decide which they want to use.

 

On the C64 you can bend the vector to your own interrupt routine, and afterwards, you could jump to the KERNAL interrupt routine, or not. As I understand it is that the console’s interrupt routine sucks, and a own interrupt routine would be desirable.

 

 

If you have questions please ask. Don't worry about posting in, and resurrecting, an old thread - that's what threads are for.

 

Thank you for the encouragement, then I won’t hesitate.

 

--------

 

OK, Textpad and WinAsm99 are working perfectly together now.

The .obj files can be loaded into Classic99 with EA3, but I can’t load them onto the real machine.

 

I tried to convert them with Ti99Dir into V9T9 format without success.

 

Of course I’d like to be able to convert them to EA5, cartridge and XB auto load, but that’s for later.

 

So how can I convert them into V9T9 format for use on the real machine, so that I can copy them with CFHDXS1?

 

Marco

Edited April 11, 2015 by Dexter

[Asmusr]

The assembler is creating object files without any header. One way around it is to create a disk image using TI99Dir and let the assembler copy the object file to the disk image. Then you can open the disk image in TI99Dir and copy the file to your HDX dir, this time with a header. You can also copy the disk image directly to your CF card using TI99Dir, which is probably the easiest.

[+Schmitzi]

for comfortable copying volumes from/to CF:

 

 

CF2-COPY-Batch-105k.zip

[Opry99er]

I like the look of that Textpad!!

[Dexter]

The assembler is creating object files without any header. One way around it is to create a disk image using TI99Dir and let the assembler copy the object file to the disk image. Then you can open the disk image in TI99Dir and copy the file to your HDX dir, this time with a header. You can also copy the disk image directly to your CF card using TI99Dir, which is probably the easiest.

I'll try that!

 

for comfortable copying volumes from/to CF:

 

 

I'd like to put that in the tool chain, only downside is that I have to swap the CF every time when I'd like to test it on the real thing.

Never the less, this surely works.

 

I like the look of that Textpad!!

Thanks, I recreated the color sceme of Matthew's TextPad screenshot.

It's pretty neat to program with it.

[Dexter]

One way around it is to create a disk image using TI99Dir and let the assembler copy the object file to the disk image. Then you can open the disk image in TI99Dir and copy the file to your HDX dir, this time with a header.

Worked like a charm!