Jump to content

Recommended Posts

I have a very limited start to such a thing. It's by no means turnkey (it won't just spit out a working cartridge), and it's exceptionally limited in what it supports, but https://github.com/tursilion/xb2gpl

 

I used it to create the MPD menu ;)

 

  • Like 3
  • Thanks 2
4 minutes ago, Retrospect said:

Can someone make a XB to GPL compiler that spits out a Cartridge image that'll run on stock console?  

Even though we've got the fantastic xb256 and compiler , an XB to GPL compiler would still be a very nice addition to what we have.  Can it be done?  I don't care that GPL is slower.  It would still be great to have.  

 

BF's two rules of software:

  1. Anything is possible
  2. Nothing is easy

:) 

  • Like 4
9 minutes ago, Tursi said:

I have a very limited start to such a thing. It's by no means turnkey (it won't just spit out a working cartridge), and it's exceptionally limited in what it supports, but https://github.com/tursilion/xb2gpl

 

I used it to create the MPD menu ;)

 

Interesting, nice work. -- i will have to check this out more.

  • Like 1
15 minutes ago, Retrospect said:

Can someone make a XB to GPL compiler that spits out a Cartridge image that'll run on stock console?  

Even though we've got the fantastic xb256 and compiler , an XB to GPL compiler would still be a very nice addition to what we have.  Can it be done?  I don't care that GPL is slower.  It would still be great to have.  

Seems @Tursi has started something like this already, check out his post about it.

 

For now GPL is slower, but I will be looking at making a faster interpreter in the future, there is no reason it can't be done, similar to how @speccery has coded a TI Basic one for his strangecart that is much faster, a similar device using an arm or pico could do the GPL work at much higher speeds, of course this would be best to be used on a newer 4A design like the 99/22 project, as to make it usable for existing software, it would require replacing the console roms on the 4A.

 

of course moving everything over to 16bit bus is another way to get speed as well, totally stop using original groms, I invision a system that auto dumps a plugged in cartridge and copies it to internal ram, and then runs from there, with on more access to old slow cartridge port and slow groms, all this can be done on newer hardware designs, just one step at a time.

 

It is also possible at least with TI Basic to run actual basic code from the GROM space, I don't think XB can do that, but alot of TI99 modules were infact written in TI Basic but the code stored in GROMs.

  • Like 6
8 hours ago, Gary from OPA said:

I invision a system that auto dumps a plugged in cartridge and copies it to internal ram, and then runs from there,

This idea was actually kicked around during the period after the 4A was released. 

 

Don Bynum's people presented an option for a "4" console with 2K of RAM added to the 16-bit bus, which could hold some code downloaded from the module.  Marketing seriously ran with this, imagining packaging for modules say "compatible with all TI-99", some new baseline 99/4B with 2K,  and then advanced modules requiring a 99/8.  There is a "99/4B Product Specification" draft documenting the 2K option.  

 

Well, that evaporated quickly, and the next design had another 16K DRAM in the console.  The engineers' cost estimate "paid for" the extra RAM through the reduction of other logic.  Semiconductor would provide Calculator division with enough PAL chips.  The price war killed that.  Bynum was told to roll the cost savings into the 4A and to forget the additions.  I pieced together this story from memos at the DeGolyer Library, the 4B documents in whtech, and other "4B" papers from Bunyard, Wilcox, et al.

 

 

  • Like 4

When they designed the p-system for the 99/4A they had the different memory types in mind. The PME is able to interpret p-code, which is a byte code too, from any kind of memory. It has two different versions of the core interpreter, depending on if the code is in non-incrementing memory (CPU RAM) or in auto-incrementing memory (VDP RAM or GROM). There's also a status word used to compute branch addresses correctly.

  • Like 2
17 hours ago, Gary from OPA said:

of course moving everything over to 16bit bus is another way to get speed as well, totally stop using original groms, I invision a system that auto dumps a plugged in cartridge and copies it to internal ram, and then runs from there, with on more access to old slow cartridge port and slow groms, all this can be done on newer hardware designs, just one step at a time.

 

My FPGA designs sort of do this, they run cartridge ROMs from 16-bit wide system memory (or with icy99 in some cases from the CPUs cache memory). My FPGA designs use internal RAM also for GROM data, that area is outside the RAM which the TMS99105 or my soft TMS9900 core can see.

  • Like 2

I had started a XB to GPL compiler but that was before FinalGROM so it was pretty clunky.

 

Of course this was over 12 years ago:

 

 

This forced me to change to just making more ROMs for XB to speed up XB with more assembly, vs slow GPL.

Edited by RXB
  • Like 3
22 hours ago, Retrospect said:

Can someone make a XB to GPL compiler that spits out a Cartridge image that'll run on stock console?  

Even though we've got the fantastic xb256 and compiler , an XB to GPL compiler would still be a very nice addition to what we have.  Can it be done?  I don't care that GPL is slower.  It would still be great to have.  

You are right that the result might run more slowly than it would in Assembly, but the resulting cartridge image would also run flawlessly on V2.2 consoles and could even combine with a huge amount of bank-switched ROM in the cartridge space with no need to lob stuff into the 32K space at all. . .that's actually a nice use case. :)

  • Like 3
7 minutes ago, Ksarul said:

You are right that the result might run more slowly than it would in Assembly, but the resulting cartridge image would also run flawlessly on V2.2 consoles and could even combine with a huge amount of bank-switched ROM in the cartridge space with no need to lob stuff into the 32K space at all. . .that's actually a nice use case. :)

would be great for those that are skilled in XB programming and want to write bigger programs and releasing it in physical format on ubergrom cartridges, giving them a large amount of space on the GROM side as ubergrom supports more than one bank of grom as well.

  • Like 3

Hi,

  I need a little push to get going.

 

 

d:\classic99_vm\gpl\mydisks\DSK2>d:\xdt99\xga99.py -c gahello.gpl -o hello.bin

d:\classic99_vm\gpl\mydisks\DSK2>dir
 Volume in drive D is phyd
 Volume Serial Number is 9223-F008

 Directory of d:\classic99_vm\gpl\mydisks\DSK2

11/09/2024  08:49 AM    <DIR>          .
11/09/2024  08:49 AM    <DIR>          ..
10/31/2024  07:33 AM             2,304 gahello.gpl
11/09/2024  08:34 AM             1,297 gahello.rpk
11/09/2024  08:49 AM             1,297 hello.bin
               3 File(s)          4,898 bytes
               2 Dir(s)  2,555,081,924,608 bytes free

 

 When I open Classic99, and load a user cartridge, the emulator reset, but I don't get a cartridge on the menu.

 

  Can someone tell me what I'm doing wrong?

 

Thanks.

24 minutes ago, dhe said:

Hi,

  I need a little push to get going.

 

 

d:\classic99_vm\gpl\mydisks\DSK2>d:\xdt99\xga99.py -c gahello.gpl -o hello.bin

d:\classic99_vm\gpl\mydisks\DSK2>dir
 Volume in drive D is phyd
 Volume Serial Number is 9223-F008

 Directory of d:\classic99_vm\gpl\mydisks\DSK2

11/09/2024  08:49 AM    <DIR>          .
11/09/2024  08:49 AM    <DIR>          ..
10/31/2024  07:33 AM             2,304 gahello.gpl
11/09/2024  08:34 AM             1,297 gahello.rpk
11/09/2024  08:49 AM             1,297 hello.bin
               3 File(s)          4,898 bytes
               2 Dir(s)  2,555,081,924,608 bytes free

 

 When I open Classic99, and load a user cartridge, the emulator reset, but I don't get a cartridge on the menu.

 

  Can someone tell me what I'm doing wrong?

 

Thanks.

The example you are using has no cartridge header.

 

Try the same but with this example file instead from the GitHub:

 

examples/gacart.gpl

 

Then it should appear in classic99 as a cartridge.

Edited by Gary from OPA

D:\classic99_vm\gpl\mydisks\DSK2>d:\xdt99\xga99.py -c gacart.gpl -o hello.bin

 

11/09/2024  10:58 AM    <DIR>          .
11/09/2024  10:58 AM    <DIR>          ..
10/31/2024  07:33 AM             1,971 gacart.gpl
11/09/2024  10:55 AM             1,261 gacart.rpk
11/09/2024  10:58 AM             1,261 hello.bin
 

Classic99 version QI399.072

 

Still doesn't work, no options chosen - fresh from the current zip file off of Tursi's website.

 

As per usual, Classic99's debugger is very helpful, but I just can't get there.

 

image.png.9227048711e7af788cb90ee993947dda.png

  • Like 1
50 minutes ago, dhe said:

D:\classic99_vm\gpl\mydisks\DSK2>d:\xdt99\xga99.py -c gacart.gpl -o hello.bin

 

11/09/2024  10:58 AM    <DIR>          .
11/09/2024  10:58 AM    <DIR>          ..
10/31/2024  07:33 AM             1,971 gacart.gpl
11/09/2024  10:55 AM             1,261 gacart.rpk
11/09/2024  10:58 AM             1,261 hello.bin
 

Classic99 version QI399.072

 

Still doesn't work, no options chosen - fresh from the current zip file off of Tursi's website.

 

As per usual, Classic99's debugger is very helpful, but I just can't get there.

 

image.png.9227048711e7af788cb90ee993947dda.png

Like the other poster says try renaming it helloG.bin as classic99 can't figure out the type.

  • Haha 1

@ralphb @Tursi

Having a bit of a trouble with xga99 and Classic99.

 

I'm trying to use the following syntax:

xga99.py -s gacart.gpl -o gacartG.bin -B

 

When I load as a user cartridge option gacartG.bin, I get:

image.png.e9b3d6af1b171c60397f856d53fbee38.png

 

If, otoh, if I do:

d:\xdt99\xga99.py -c  -s gacart.gpl

 

I get:

 gacart.rpk

 and I change this to a zip, and extract, I get a gcart.bin, renaming this file to gcartG.bin and then using load user cart gcartG.bin you get:

 

image.png.388f9ec0ded60510392c27f8e8e55ed8.png

 

Is there a less cumbersome way of doing this?

 

 

  • Like 1
3 hours ago, dhe said:

ok - with Gary's help.

 

d:\xdt99\xga99.py gacart.gpl -o gacart2G.bin -G 24576

 



 

Yeah. Strange thing is with -cart option it makes a rpk with the binary inside perfect.

 

But if you want it for finalgrom99 or classic99 you need to tell it the grom starting address and even tho the document says you can do --grom 3 or --grom 6000 it doesn't work you need to specify the starting address in decimal on the command line not in hexadecimal. So for >6000 you use 24576

  • Like 2

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