TI-GROMmy, the system GROM replacement

[Artoj]

Hyvää päivää,

I have been looking at the console and there are 3 pins not used on the TMS9901, 38+37+29 - P0 P1 P10, where P10/INT12 is set high with a 10K resistor. These spare CRU lines could be used to implement a MIDI, I2C or SPI interface or even a RS232, so without too many hardware lines to get a simple device service routine to be incorporated into a console GROMmy. This could add so much to the bare console by adding a few new calls, such as CALL MIDI(INOUT,DATA$) or CALL I2C(INOUT,DATA) etc... maybe not even calls but just as Basic commands that can be used to manipulate data for each type of device. Regards Arto. 

Edited October 31, 2023 by Artoj

[GDMike]

Sounds like a prototype board needs made..hmmm

[speccery]

I've been a little under the weather and watched some retrocomputer related videos. I discovered a ZX Spectrum project from Spain, the Dandanator and its extensions. I studied this project and the code in Github briefly. This somehow motivated me to continue with the grommy2 firmware development, and I was able to spare a few hours during the weekend to work on it. The basic realisation for me was just that I need to limit the feature set to something useful to be able to get a better full-fledged firmware out. A device like the grommy2 can do so many things, that it's easy enter the idea land which leads to feature creep...

 

So I decided to put in some constraints, and I would be interested in feedback from the community. What follows is what I decided to do, and I have already written in the firmware. I have tested most of these features already in isolation on dev board, but I haven't yet tested any of this running when the board connected to the TI. Since the previous firmware version was already working well, I have no reason to think this would be hard to get running.

 

This is the feature set:

• Four 24K memory banks covering the system GROM area. One of these is active for reads at a time.
  • #0 normal TI-99/4A system GROMs, stored in Flash. This is the default. Read only.
  • #1 user system GROM bank 1, stored in flash. Read only.
  • #2 user system GROM bank 2, stored in flash. Read only.
  • #3..#7 reserved
  • #8 24K GRAM area stored in RAM. By default read only, but writes can be enabled. The RAM area works as a shadow area: when writes are enabled, the written data goes to this RAM, regardless what GROM bank is chosen for reads.
• Command interface at GROM address 0x5FF0 (last 16 bytes of the system GROM area)
  • By writing 16-byte commands to this memory area, the grommy2 will perform certain tasks
  • The simple command interface implementation means that the system GROM code cannot use the last 16 bytes of GROM. 
  • Since normal TI GROM chips are 6k each, occupying a 8k memory slot in the GROM address space - with 2k dummy data at the end - the command interface does not interfere with standard system GROMs. I know there are some extensions of the system GROMs, and if they use these very last 16 bytes there might be a problem. I hope in practice not, and if that happens, the interface can be modified.
• Commands. At this point there are a 8 commands, invoked by writing a 16 byte command to 0x5FF0 continuously. The commands are:
  • 0: Read version. Makes the grommy2 firmware version information available for reads at address 0x5FF0..0x5FF7.
  • 1: Select GROM bank to be used for system GROM reads. Valid banks are 0..2 for Flash and 8 for GRAM.
  • 2: Copy a Flash bank to GRAM, valid banks are 0,1 and 2.
  • 3: Enable/disable RAM shadow mode. When enabled, writes to system GROM area go to GRAM (bank 8).
  • 4: Write contents of GRAM to Flash bank 1 or 2. One parameter of the write command is a bit mask, choosing in 4k chunks what parts of the GRAM to write to Flash. This can be the entire 24K, or any combination of 4k areas in the 24k system GROM range.
  • 5: Compare contents of GRAM to flash bank 0,1 or 2. 
  • 6: Write the contents of GRAM as new firmware for the grommy2. Needless to say this command is dangerous, but allows updating the firmware while the grommy2 is inside the TI without any debugging cables etc.
  • 7: Execute code in the GRAM region by the ARM processor of the grommy2.

In addition to the above, I will modify the firmware so that it monitors one of the spare I/O pins of the grommy2 when it boots. Depending on the level of the I/O pin, the grommy2 will boot with Flash bank 0 or 1. This makes it possible to run custom GROM code from the boot.

 

The command set above I think is enough to enable all kinds of use cases:

• GRAM mode: Copy one of the flash banks 0,1 or 2 to RAM. Switch to RAM bank. Enable shadow ram writes.
• Run custom system GROM: Select user bank 1 or 2.
• Write custom GROM contents: enable shadow RAM mode, write new GROM contents by just writing to the system GROM area, and finally issue the command to write the contents of GRAM to flash user bank 1 or 2. After this the contents are non volatile and can be entered by just selecting that bank for reads. Note that the normal system GROM bank can be active for reads throughout this process.
• Update firmware: enable shadow RAM mode, write new firmware contents by just writing to the system GROM area, and finally issue the command to write the contents of GRAM as new firmware. Note that the normal system GROM bank can be active for reads throughout this process. The system probably needs to be reset after this... I haven't tested this functionality yet.

Feedback is welcome.

 

Edited November 12, 2023 by speccery

[speccery]

I spent this weekend a couple of solid sessions on improving the grommy2 firmware and testing it. It now has a pretty solid level of functionality, I still need to test the firmware upgrade capability though. I also took some time to write a document about the grommy2 software interface, it's available here in the StrangeCart-Doc documentation tree. It's not the right place for the document, but I wanted to make it available for review immediately.

 

As the document explains, I used some GPL code on a modified version of the Mini Memory cartridge to test the grommy2. Out of the eight commands I outlined in the previous message I have tested five - including flashing of the MCU inside of the TI under the control of TMS9900! In other words, I was able to use GPL code to first copy default GROM to GRAM, enable shadow RAM (i.e. writes) and select the GRAM bank, edit the contents of system GROM/GRAM with a modified version of Easybug, and finally write the modified version to the Flash memory of the grommy2. I tested this with both user banks, programmed them back to the grommy2 and powered off the computer. After powering on again I re-entered Easybug and switched back to user GROM area - and the changes remained!

 

I also realised that the GRAM area can be used as a 24k memory expansion of sorts, and started to think of adding a couple of calls to normal TI BASIC for example to move strings back and forth the GRAM area... I am happy I took the time a week ago to think about the specs as above and got some structure into this project.

 

Edited November 19, 2023 by speccery

[RXB]

Looking at the specs this is going to just kill most any GROM/GRAM programs ever written by Miller Graphics and just about everyone else that has owned a GRAM device.

As the limit to 6K GROMs with >5FF0 being used by some TI GROMs ONLY you could not even load them without modifications to function.

I guess as you are going to write everything yourself in the future for the device, backward compatibility is a non starter.

 

I am not a hardware guy, but I know what is required to make GROM/GRAM function in a device that uses it.

[speccery]

Thanks @RXB for the feedback. I was looking for this. Before I respond to your comments, a couple of pieces of background information:

• the grommy2 is a system GROM replacement device. Due to this, it only has access to GROM signals. It is not connected to CRU signals nor can it act as a normal RAM or ROM. It can only do its thing in the GROM space. It cannot support multiple GROM bases, since being compatible with the GROM chip pinout it is not connected to extra address lines. 
• I on purpose limited the address range it covers to the system GROM area. Remember that this thing plugs inside the console in the place of the GROM chips. If the grommy2 was to serve GROM addresses beyond 24K, it would conflict with GROMs connected to the cartridge port. Unlike the normal system GROM chips with weak data bus drivers, the grommy2 has strong drivers and would overpower GROMs connected to the cartridge port.

11 hours ago, RXB said:

As the limit to 6K GROMs with >5FF0 being used by some TI GROMs ONLY you could not even load them without modifications to function.

As the documentation says, it operates always in 8K GROM mode. So not 6K but 8K per GROM for a total of 24K with 3 GROMs. The exception is that the command interface is at address 5FF0, masking the top 16 bytes of the 3rd 8K GROM. Indeed the command interface, being at the top of 8K GROM slot #3 does not interfere with any 6K GROMs. I can make the command interface more sneaky to enable access to those 16 last bytes in the system area if needed. I can place it anywhere in the GROM space, for example to FFF0..FFFF.

 

The grommy2 could easily serve the entire 64K GROM space, but the problem is, what happens if you plug in a cartridge? I suppose I could add some sensing code to only serve the area from >6000 onwards if nobody else is driving the bus then, but that functionality would need to rely on heuristics.

 

11 hours ago, RXB said:

I am not a hardware guy, but I know what is required to make GROM/GRAM function in a device that uses it.

Please enlighten me, I posted the spec to collect feedback. Please also note that there are other devices, like my StrangeCart cartridge, which can act as a large GRAM and large RAM/ROM simultaneously.

With regards to hardware vs software know-how, I do much more software than hardware, also professionally I've done much more software than hardware design. I enjoy both  

Edited November 20, 2023 by speccery

[RXB]

64K GROM space? 

GROM 0, GROM 1 and GROM 2 would be 18K GROM that is 3 6K GROMs.

So 32K GROM cartridge plus 18K is 50K GROM total in TI99/4A Console with a TI Cartridge.

Hmm 50K does not equal 64K

 

3rd party like GRAMKRACKER was 40K GROM Cartridge space plus 3 8K GROMs add up to 64K.

40K Cartridge space most 3rd party like GRAMKRACKER XB or SXB or RXB or XB 2.9 all use 8K GROMs.

GRAMKRACKER was 3 8K GROMs would be 24K GROM in 3 8K GROMs.

Thus 40K plus 24K is 64K

 

If GROMMY 3 6K GROMs that is only 18K so were are you getting 64K total?

Is my math here wrong?

 

[speccery]

1 hour ago, RXB said:

If GROMMY 3 6K GROMs that is only 18K so were are you getting 64K total?

I don't know where you get this idea of 3*6k capacity with the grommy2. I have all the time communicated that the grommy2 does 3*8k in the system GROM area (meaning the bottom 3 GROMs, total 24k). When loaded with original TI system GROM contents, then only 6k of each of the 3 GROMs contains useful data, and the top 2K of each 3 GROM areas (1800..1FFF, 3800..3FFF, 5800..5FFF) is unused - or available for extensions.

The grommy2 has enough flash memory space to provide another 40k on top of the bottom 24K, making a total of 64k. That is not implemented in the current firmware, but would be easy to do - if it makes sense.

[RXB]

10 hours ago, speccery said:

I don't know where you get this idea of 3*6k capacity with the grommy2. I have all the time communicated that the grommy2 does 3*8k in the system GROM area (meaning the bottom 3 GROMs, total 24k). When loaded with original TI system GROM contents, then only 6k of each of the 3 GROMs contains useful data, and the top 2K of each 3 GROM areas (1800..1FFF, 3800..3FFF, 5800..5FFF) is unused - or available for extensions.

The grommy2 has enough flash memory space to provide another 40k on top of the bottom 24K, making a total of 64k. That is not implemented in the current firmware, but would be easy to do - if it makes sense.

Cool thanks my misunderstanding from previous post it sounded like only 6K GROMs.

[speccery]

My next step in this project is a program, running on the TI and probably written in GPL, which will create a simple user interface to display the status of the grommy2 and to perform the typical tasks such as enabling GRAM and copying stuff to it from one of the user GROM banks. I wanted to have some graphics in that as well, and I ended up creating a simple python3 program which converts a 1bpp BMP format picture into a TI Basic program drawing the picture - as long as there are enough user characters available. I'm not going to implement the final program in Basic, but this was a quick way to test that the conversion works and a fun exercise.

 

The code of the python program 1bpp2basic.py is available and "documented" at GitHub:

the tool in GitHub

 

Here is the generated BASIC program for the test program. Thus the input is a picture and output SCREEN.BAS listed below.

Spoiler

1000 REM CREATED FROM grommy2a_config-1bpp.bmp
1010 CALL CLEAR
1020 CALL CHAR(96, "0000000000000000")
1030 CALL CHAR(97, "000000030F1F3F3F")
1040 CALL CHAR(98, "000000F0FCFEFFFF")
1050 CALL CHAR(99, "0000000000000080")
1060 CALL CHAR(100, "1C3F7FFFFFFEFEFE")
1070 CALL CHAR(101, "003FFFFFFF7F7F7F")
1080 CALL CHAR(102, "003F3F3F3F3F3F3F")
1090 CALL CHAR(103, "009CBCFCFCFDFDFD")
1100 CALL CHAR(104, "073F7FFFFFFCFCFC")
1110 CALL CHAR(105, "00F0F8FCFEFEFEFE")
1120 CALL CHAR(106, "069FFFFFFF9F9F9F")
1130 CALL CHAR(107, "038FDFFFFFE7C7C7")
1140 CALL CHAR(108, "00C7E7E7E7F7F7F7")
1150 CALL CHAR(109, "00F3FFFFFFF3F3F3")
1160 CALL CHAR(110, "C0F1FBFFFFFCF8F8")
1170 CALL CHAR(111, "60F8FCFCFCFEFEFE")
1180 CALL CHAR(112, "00FCFEFE7E7E7E7E")
1190 CALL CHAR(113, "003F3F7F7F7F7E7E")
1200 CALL CHAR(114, "7F7E7E7E7E000000")
1210 CALL CHAR(115, "3F3F3F3F3F7F7FFF")
1220 CALL CHAR(116, "8080808080800000")
1230 CALL CHAR(117, "FEFEFEFEFEFEFEFE")
1240 CALL CHAR(118, "7F7F7F7F7F7F7F7F")
1250 CALL CHAR(119, "3F3F3F3F3F3F3F3F")
1260 CALL CHAR(120, "F9C1C18181818181")
1270 CALL CHAR(121, "FCFCFCFCFCFCFCFC")
1280 CALL CHAR(122, "9F9F9F9F9F9F9F9F")
1290 CALL CHAR(123, "C7C7C7C7C7C7C7C7")
1300 CALL CHAR(124, "F7F7F7F7F7F7F7F7")
1310 CALL CHAR(125, "F3F3F3F3F3F3F3F3")
1320 CALL CHAR(126, "F8F8F8F8F8F8F8F8")
1330 CALL CHAR(127, "7E3F3F3F3F3F1F1F")
1340 CALL CHAR(128, "7E7E7E7E7E7EFCFC")
1350 CALL CHAR(129, "0001010307070F0F")
1360 CALL CHAR(130, "FFFEFCFCF8F8F0E0")
1370 CALL CHAR(131, "FEFF7F7F3F00FEFE")
1380 CALL CHAR(132, "7FFFFFFF7F7F7F7F")
1390 CALL CHAR(133, "8181818180808080")
1400 CALL CHAR(134, "FCFCFCFCFFFF7F1F")
1410 CALL CHAR(135, "FEFEFEFEFCFCF8E0")
1420 CALL CHAR(136, "1F1F1F0F0F0F0F1F")
1430 CALL CHAR(137, "FCFCFCFCFCFCF8F8")
1440 CALL CHAR(138, "1F3F3F7F7F7F7F7F")
1450 CALL CHAR(139, "E0C080FFFFFFFFFF")
1460 CALL CHAR(140, "0000000080808080")
1470 CALL CHAR(141, "FF7F3F0F00000000")
1480 CALL CHAR(142, "FFFEFCF000000000")
1490 CALL CHAR(143, "3F3F3F0000000000")
1500 CALL CHAR(144, "F8F0E00000000000")
1510 CALL CHAR(145, "0000003E60606060")
1520 CALL CHAR(146, "0000003E6643C343")
1530 CALL CHAR(147, "00000063737B6F6F")
1540 CALL CHAR(148, "0000007C60607C60")
1550 CALL CHAR(149, "000000C7CCCCCCCC")
1560 CALL CHAR(150, "000000C00000C0E0")
1570 CALL CHAR(151, "60321E0000000000")
1580 CALL CHAR(152, "62763C0000000000")
1590 CALL CHAR(153, "6767630000000000")
1600 CALL CHAR(154, "6060600000000000")
1610 CALL CHAR(155, "CCCEC70000000000")
1620 CALL CHAR(156, "60E0C00000000000")
1630 CALL HCHAR(1,1,96, 768)
1640 GOTO 1730
1650 FOR I=1 TO LEN(A$)
1660 CALL HCHAR(Y, X+I-1, ASC(SEG$(A$,I,1))+50)
1670 NEXT I
1680 RETURN
1730 X=23
1740 Y=2
1750 A$="/01"
1760 GOSUB 1650
1770 X=8
1780 Y=3
1790 A$="234567489:;<=>?@AB"
1800 GOSUB 1650
1810 X=8
1820 Y=4
1830 A$="CDEFGCEHIJKLCMNOP"
1840 GOSUB 1650
1850 X=8
1860 Y=5
1870 A$="QRESTUEHIJKLCVWXYZ"
1880 GOSUB 1650
1890 X=8
1900 Y=6
1910 A$="[\"
1920 GOSUB 1650
1930 X=21
1940 Y=6
1950 A$="]^_`abcd"
1960 GOSUB 1650
1970 X=23
1980 Y=7
1990 A$="efghij"
2000 GOSUB 1650
2110 GOTO 2110

 

 

Here is the output captured from js99er.net after running the program:

[speccery]

I updated the '1bpp2basic.py' python script so that it now also creates a GPL version of the screen definition  The new version is on my Github repository.

I also created a module header & setup program called config.gpl (inspired by the setup code from Mini Memory) which includes the generated screen.gpl code and draws the screen. The code is compiled with 

python3 1bpp2basic.py
xga99.py --aorg 0x6000 config.gpl -L config.lst -o config.bin

and the generated config.bin file is a small GROM image which can be loaded with js99er.net. Since the name ends with a 'g' the emulator detects its a GROM. The BASIC program SCREEN.BAS is still generated as well. Compared to the BASIC program, the GPL code is more compact (if you only consider the screen definition) and very fast.

Below is the output rendered by the example GPL, I also attach the GROM image 'config.bin' which can be loaded to an emulator. It is not very interesting, as there is no interaction. But anyway this completes the workflow from a 1bit per pixel BMP image to a GROM image. Also, the source code config.gpl might be interesting to someone willing to learn GPL (I still learning myself).

config.bin

[Artoj]

On 11/27/2023 at 6:28 AM, speccery said:

Also, the source code config.gpl might be interesting to someone willing to learn GPL (I still learning myself).

Thank you so much, I will be going through a thorough GPL learning session soon and I will need every titbit to move forward. any suggestions on reading material to make things easier. Regards Arto. 

[speccery]

12 hours ago, Artoj said:

Thank you so much, I will be going through a thorough GPL learning session soon and I will need every titbit to move forward. any suggestions on reading material to make things easier. Regards Arto. 

Hi Arto, my source of information and inspiration with GPL have been the TI intern book (available in PDF format, contains disassembly of ROM TMS9900 code and system GROM disassembly in GPL). However, like I mentioned, the TI Mini Memory module's GPL disassembly files and explanation here are easier to approach and play with. I have said it before, and I will probably say it again in the future, but as a kid I really should have bought the Mini Memory Cartridge instead of extended Basic. They were both bloody expensive at that time and had the same price. 

Edited November 30, 2023 by speccery

[RXB]

17 hours ago, Artoj said:

Thank you so much, I will be going through a thorough GPL learning session soon and I will need every titbit to move forward. any suggestions on reading material to make things easier. Regards Arto. 

RXB 2023 has everything included to make or modify GPL, Assembler, Disassembler and 42,600 lines of code in GPL and Assembly all commented.

RXB 2023.zip

[+Ksarul]

10 hours ago, RXB said:

RXB 2023 has everything included to make or modify GPL, Assembler, Disassembler and 42,600 lines of code in GPL and Assembly all commented.

RXB 2023.zip 13.95 MB · 6 downloads

That's a good start on sources of GPL information, but another possible suggestion would be to look at the GPL source code available for several other TI cartridges as well (a lot of it is linked in the resources thread). Every one of them includes a neat new trick or three to wring just a bit more out of GPL.

[speccery]

I created the first version of the config tool for grommy2. I continued to write this on GPL. There are two screens, and single keystroke commands (in the time honored way commands are issued on the TI) are used to perform actions. Here is the main screen, under js99er.net. I have also run this on the real hardware. The version number is 0.0.99 when grommy2 is not detected.

The second screen, accessed with command 9, has a GROM dump tool. It also will have the ability to flash a new firmware, provided it has somehow been loaded to the 24K GRAM. Here is a screenshot:

I attach the new config.bin, a GROM cartridge image which can directly be loaded with js99er or presumably any other emulator. It can be tested (the GROM dumping thing) without a grommy2, it will just show contents of GROM. But this is shockingly slow! Probably the GPL code could be optimised further. The source code config.gpl can be found here. This second screen is a bit cryptic, but there are 4 commands:

1 : Decrement GROM address by 64 (hex 40) and dump 64 bytes

2 : Increment GROM address by 64 and dump 64 bytes

3 : return to previous screen.

0 : flash firmware (not implemented yet but trivial)

So here pushing 1 or 2 will show the next crop of 64 bytes of GROM contents. But it is dead slow, you can see as the progress as the code updates the next page. I did not have high expectations for GPL execution speed, but this still is slower than I expected (haven't tried this screen on the real iron yet). Given that for me it is much harder and slower to write GPL than assembler code, I really was hoping this would go faster. Well, a piece of GPL code can always copy machine code snippets from GROM to the scratchpad memory and use the GPL instruction XML to run it, perhaps that's the way to go. I went with GPL since I want this config tool to run from the grommy2 without additional hardware (the code is currently less than 2K and will fit into the unused areas of GROM space).

 

Then a question: to update the firmware, the new firmware needs come from somewhere. Perhaps it should be in a disk file. Does anyone have a piece of GPL code which would load binary data from disk? I also wonder what would the right format for a disk file, probably a 80 byte fixed record file as there are no pure binary streams to my understanding available. What I need is a way to load 24K of payload from a file to GRAM. A simple way would be use the LOAD PAB opcode, but that is limited to what can fit in the VDP RAM given the way the TI works. I could break the 24K firmware to three 8K files, which would then be loaded with the LOAD command to VDP RAM and copied from there to GRAM 8K at a time. But it would be better if the firmware was stored in a single file.

config.bin

Edited December 3, 2023 by speccery

[RXB]

1 hour ago, speccery said:

I created the first version of the config tool for grommy2. I continued to write this on GPL. There are two screens, and single keystroke commands (in the time honored way commands are issued on the TI) are used to perform actions. Here is the main screen, under js99er.net. I have also run this on the real hardware. The version number is 0.0.99 when grommy2 is not detected.

The second screen, accessed with command 9, has a GROM dump tool. It also will have the ability to flash a new firmware, provided it has somehow been loaded to the 24K GRAM. Here is a screenshot:

I attach the new config.bin, a GROM cartridge image which can directly be loaded with js99er or presumably any other emulator. It can be tested (the GROM dumping thing) without a grommy2, it will just show contents of GROM. But this is shockingly slow! Probably the GPL code could be optimised further. The source code config.gpl can be found here. This second screen is a bit cryptic, but there are 4 commands:

1 : Decrement GROM address by 64 (hex 40) and dump 64 bytes

2 : Increment GROM address by 64 and dump 64 bytes

3 : return to previous screen.

0 : flash firmware (not implemented yet but trivial)

So here pushing 1 or 2 will show the next crop of 64 bytes of GROM contents. But it is dead slow, you can see as the progress as the code updates the next page. I did not have high expectations for GPL execution speed, but this still is slower than I expected (haven't tried this screen on the real iron yet). Given that for me it is much harder and slower to write GPL than assembler code, I really was hoping this would go faster. Well, a piece of GPL code can always copy machine code snippets from GROM to the scratchpad memory and use the GPL instruction XML to run it, perhaps that's the way to go. I went with GPL since I want this config tool to run from the grommy2 without additional hardware (the code is currently less than 2K and will fit into the unused areas of GROM space).

 

Then a question: to update the firmware, the new firmware needs come from somewhere. Perhaps it should be in a disk file. Does anyone have a piece of GPL code which would load binary data from disk? I also wonder what would the right format for a disk file, probably a 80 byte fixed record file as there are no pure binary streams to my understanding available. What I need is a way to load 24K of payload from a file to GRAM. A simple way would be use the LOAD PAB opcode, but that is limited to what can fit in the VDP RAM given the way the TI works. I could break the 24K firmware to three 8K files, which would then be loaded with the LOAD command to VDP RAM and copied from there to GRAM 8K at a time. But it would be better if the firmware was stored in a single file.

config.bin 1.95 kB · 1 download

Included with RXB 2023 package is all the utilities I use to make and distribute RXB.

GPL Assembler

GPL Disassembler

GPL@LOADER (this loads GPL object code created by the GPL Assembler)

The GPL@LOADER can loads 40K of GRAM into Cartridge space in one file in that it is one huge Object file.

Normally I just load 8K chucks but it can do the entire GRAM space from >0000 to >FFFF

Thus you could make a single file to load all GRAM space in the TI99/4A in a single file from GPL@LOADER

[RXB]

RXB 2023 ZIP FILE

RXB 2023.zip

[F.G. Kaal]

On 12/3/2023 at 7:59 PM, speccery said:

I also wonder what would the right format for a disk file, probably a 80 byte fixed record file as there are no pure binary streams to my understanding available.

For other purposes where a binary stream is needed the file type INT/FIX 128  or DIS/FIX 128 is used. The advantage is that 256 bytes are stored on 2 records.

 

examples:

ARC files INT/FIX 128

GIF files DIS/FIX 128

 

Fred

[speccery]

18 minutes ago, F.G. Kaal said:

For other purposes where a binary stream is needed the file type INT/FIX 128  or DIS/FIX 128 is used. The advantage is that 256 bytes are stored on 2 records.

 

examples:

ARC files INT/FIX 128

GIF files DIS/FIX 128

 

Fred

Thanks Fred, this is the information I was looking for! The INT/FIX 128 format is probably the best for me.

[speccery]

On 12/3/2023 at 10:29 PM, RXB said:

Included with RXB 2023 package is all the utilities I use to make and distribute RXB.

GPL Assembler

GPL Disassembler

GPL@LOADER (this loads GPL object code created by the GPL Assembler)

The GPL@LOADER can loads 40K of GRAM into Cartridge space in one file in that it is one huge Object file.

Normally I just load 8K chucks but it can do the entire GRAM space from >0000 to >FFFF

Thus you could make a single file to load all GRAM space in the TI99/4A in a single file from GPL@LOADER

Thanks, I took a look at the files. There is no documentation how to use GPL@LOADER here, it seems to be an executable program. I assume it is part of the GRAM Kracker software. It does not appear there is source code, that's really what I was looking for. How is GPL@LOADER used? Do you load it with E/A or how does one launch it?

[RXB]

3 hours ago, speccery said:

Thanks, I took a look at the files. There is no documentation how to use GPL@LOADER here, it seems to be an executable program. I assume it is part of the GRAM Kracker software. It does not appear there is source code, that's really what I was looking for. How is GPL@LOADER used? Do you load it with E/A or how does one launch it?

On AtariAge I have a GPL Tutorial called GPLHOW2 SERIES

 

(I explain how to use all these tools in the videos)

 

TI-99/4A development resources - TI-99/4A Development - AtariAge Forums

[+acadiel]

On 12/3/2023 at 1:59 PM, speccery said:

Then a question: to update the firmware, the new firmware needs come from somewhere. Perhaps it should be in a disk file. Does anyone have a piece of GPL code which would load binary data from disk? I also wonder what would the right format for a disk file, probably a 80 byte fixed record file as there are no pure binary streams to my understanding available. What I need is a way to load 24K of payload from a file to GRAM. A simple way would be use the LOAD PAB opcode, but that is limited to what can fit in the VDP RAM given the way the TI works. I could break the 24K firmware to three 8K files, which would then be loaded with the LOAD command to VDP RAM and copied from there to GRAM 8K at a time. But it would be better if the firmware was stored in a single file.

config.bin 1.95 kB · 7 downloads

Question:  Can we load it from a bank switched cart at >6000 (kind of like Tursi helped do with the F18A Updater cartridge)?  That's 8K x however many banks you need - possibly a 32K 27256 EPROM is all that's needed.  (Code + the firmware put together into one image burned to the EPROM).  That means also that a FinalGROM or FinalROM user can also load the cart image too, as well as a regular EPROM cart user (UberGROM, Guidry board, red board, black board, 64K board, etc.)

[speccery]

On 12/19/2023 at 11:41 PM, acadiel said:

Question:  Can we load it from a bank switched cart at >6000 (kind of like Tursi helped do with the F18A Updater cartridge)?  That's 8K x however many banks you need - possibly a 32K 27256 EPROM is all that's needed.  (Code + the firmware put together into one image burned to the EPROM).  That means also that a FinalGROM or FinalROM user can also load the cart image too, as well as a regular EPROM cart user (UberGROM, Guidry board, red board, black board, 64K board, etc.)

Yes, sure. This was my original thought, before I started to think that loading from disk could be easier for some. I will make an example cartridge image in the coming days.