xdt99: New TI 99 cross-development tools available

[mr_gw454]

22 minutes ago, ralphb said:

That really depends on your distribution.

 

On Debian-based distributions, you can choose which Python version to start by running

update-alternatives --config python

For other distributions, you could edit the first line of each program (recommended), as you suggested, or create an alias python=python3 (which will not work for xhm99/xvm99).  And you can still use the old version of xdt99 by selecting "python2" in the branch selector on GitHub, or downloading an old release.

 

Please note that Python 2 has been out of maintenance since the beginning of this year.  Ubuntu 20.04 doesn't even ship Python 2 any more.

 

I appreciate the info.  It sounds like there are some easy options for resolving the issue.

 

Thanks!

[Michael Rittweger]

On 1/11/2015 at 3:24 PM, ralphb said:

The TI 99 Cross-Development Tools (xdt99) are planned as a suite of programs to facilitate the development of programs for the TI 99 family of home computers on modern computer systems.

 

Hi, Ralph!

 

I just wanted to step in and say "thank you" for the cross-assembler and the companying tools.

 

I have set up an environment through a DOS batch combining xas99, xdm99, NotePad++ and MAME that helps saving typing a lot:

 

So now I just have to E, A, R, I, D, M to have a complete workflow from editing to starting up Editor/Assembler and "load and run" the output.

 

Special thanks for the xdm that creates a disk file with the needed files ready to mount with MAME.

 

Michael

 

[ralphb]

You're welcome!

 

Your environment looks very interesting.  It's basically a GUI for xdt99! ?  I'm sure other people might be interested in that tool.  Have you thought about sharing it?

 

[Michael Rittweger]

1 hour ago, ralphb said:

Have you thought about sharing it?

 

Well, it's far from "ready", but if someone wants to habe a glimpse... ;-)

 

It makes heavy use of setting (and combining) DOS environment variables. But they are all "cleaned up" when exiting through (Q)uit.

 

Pro: An "echo" here and there could show up problems like "Debug.Print()" or "Console.WriteLine()". Con: All that % create an awkward syntax.

 

(And "awkward syntax" was the reason to fork to TurboPasc99 instead of c99 that days.)

 

In fact that DOS batch started as a sketch to have a blueprint for creating a "real" IDE coded in C# or VB.Net. Well, if time permits...

 

As a purist I'm not that happy using things like calling subroutines (TOUPPERCASE) or using "choice" in the batch. But on the other hand... It's the 21st century and I'm still dealing with a gray/black CLI, so what am I complaining about? ;-)

 

I should say some words about the using, or at least the adapting. I'll make another post for that.

 

Michael

 

And here it goes:

@echo off
cls
setlocal enabledelayedexpansion

:param1
if [%1] == [] goto noproject
set ti99_prj=%1
goto param2
:noproject
rem ...
goto quit

:param2
if [%2] == [] goto defaultsource
set ti99_wrk=%2
goto setfiles
:defaultsource
set ti99_wrk=%ti99_prj%
:setfiles
set ti99_src=%ti99_wrk%.a99
set ti99_obj=%ti99_wrk%.obj
set ti99_lst=%ti99_wrk%.lst
set ti99_img=%ti99_wrk%.img
set ti99_rpk=%ti99_wrk%.rpk
set ti99_dsk=%ti99_prj%.dsk

:settings
set wrk_drv=E:
set wrk_dir=\Spiele\MAME\TI99\
set xdt_drv=E:
set xdt_dir=\Spiele\MAME\TI99\xdt99\
set xdt_prj=%xdt_dir%projects\
set xdt_lib=%xdt_dir%lib\
set xdt_ed="C:\Program Files (x86)\Notepad++\notepad++.exe"
set xdt_as=xas99.py
set xdt_dm=xdm99.py
set dsk_img=%ti99_wrk:~0,9%
call :TOUPPERCASE dsk_img
set dsk_asm=%dsk_img%A
set dsk_obj=%dsk_img%O
set dsk_lst=%dsk_img%L

set emu_drv=E:
set emu_dir=\Spiele\MAME\
set emu_bin=mame64.exe
set emu_par=ti99_4ev
set emu_par=%emu_par% -gromport single
set emu_par=%emu_par% -cart editass
set emu_par=%emu_par% -ioport peb
set emu_par=%emu_par% -ioport:peb:slot2 evpc
set emu_par=%emu_par% -ioport:peb:slot2:evpc:colorbus busmouse
set emu_par=%emu_par% -ioport:peb:slot4 speech
set emu_par=%emu_par% -ioport:peb:slot6 tirs232
set emu_par=%emu_par% -ioport:peb:slot8 hfdc
set emu_par=%emu_par% -ioport:peb:slot8:hfdc:f1 525dd
set emu_par=%emu_par% -ioport:peb:slot8:hfdc:f2 525dd
set emu_par=%emu_par% -ioport:peb:slot8:hfdc:f3 525dd
set emu_par=%emu_par% -ioport:peb:slot8:hfdc:f4 525dd
set emu_par=%emu_par% -ioport:peb:slot8:hfdc:h1 generic
set emu_par=%emu_par% -ioport:peb:slot8:hfdc:h2 generic
set emu_par=%emu_par% -ioport:peb:slot8:hfdc:h3 generic
set emu_par=%emu_par% -flop1 ti99/disk/edassa.dsk
set emu_par=%emu_par% -flop3 ti99/disk/flopdsk3.dsk
set emu_par=%emu_par% -flop4 ti99/disk/flopdsk4.dsk
set emu_par=%emu_par% -hard1 ti99/hard/harddsk1.chd
set emu_par=%emu_par% -hard2 ti99/hard/harddsk2.chd
set emu_par=%emu_par% -hard3 ti99/hard/harddsk3.chd
rem set emu_par=%emu_par% -flop2 flopdsk2.dsk

%xdt_drv%
cd %xdt_drv%%xdt_prj%%ti99_prj%
for %%g in (*.a99) do (
  set file1=%%g
  set file2=!file1:.a99=a!
  call :TOUPPERCASE file2
  echo        %%g --- !file1! --- !file2!
  set file1=
  set file2=
)
for %%g in (*.obj) do (
  set file1=%%g
  set file2=!file1:.obj=o!
  call :TOUPPERCASE file2
  echo        %%g --- !file1! --- !file2!
  set file1=
  set file2=
)
for %%g in (*.lst) do (
  set file1=%%g
  set file2=!file1:.lst=l!
  call :TOUPPERCASE file2
  echo        %%g --- !file1! --- !file2!
  set file1=
  set file2=
)
for %%g in (*.img) do (
  set file1=%%g
  set file2=!file1:.img=!
  call :TOUPPERCASE file2
  echo        %%g --- !file1! --- !file2!
  set file1=
  set file2=
)
%xdt_drv%
cd %xdt_dir%
rem goto quit

%xdt_drv%
cd %xdt_dir%

goto showsettings

rem ***************************************************************************

:loop
%wrk_drv%
cd %wrk_dir%
echo.
echo -------------------------------------------------------------------------------
echo (E) edit source file                    (A) assemble E/A 3 object file
echo (R) create MESS .rpk file               (I) create E/A 5 image file
echo (D) create MAME .dsk file               (S) show settings / used files
echo (M) emulator start                      (Q) quit
echo.
choice /c EARIDSMQ /N /m "Choice: E, A, R, I, D, S, M, Q > "
echo.
if %errorlevel% EQU 8 goto quit
if %errorlevel% EQU 7 goto emulator
if %errorlevel% EQU 6 goto showsettings
if %errorlevel% EQU 5 goto disk
if %errorlevel% EQU 4 goto image
if %errorlevel% EQU 3 goto mess
if %errorlevel% EQU 2 goto assemble
if %errorlevel% EQU 1 goto edit
if %errorlevel% EQU 0 goto loop
goto loop

rem ***************************************************************************

:edit
echo (E)dit
echo %xdt_drv%%xdt_prj%%ti99_prj%\%ti99_src%
%xdt_drv%
cd %xdt_prj%%ti99_prj%
%xdt_ed% %ti99_src%
goto loop

rem ***************************************************************************

:assemble
echo (A)ssemble for EA3
echo %xdt_drv%%xdt_prj%%ti99_prj%\%ti99_obj% / %ti99_lst%
%xdt_drv%
cd %xdt_prj%%ti99_prj%
%xdt_as% -R -S -I %xdt_drv%%xdt_lib% -L %ti99_lst% %ti99_src%
goto loop

rem ***************************************************************************

:mess
echo (R)pk for MESS
echo %xdt_drv%%xdt_prj%%ti99_prj%\%ti99_rpk%
%xdt_drv%
cd %xdt_prj%%ti99_prj%
%xdt_as% -R -S -I %xdt_drv%%xdt_lib% -c %ti99_src%
goto loop

rem ***************************************************************************

:image
echo (I)mage for EA5
echo %xdt_drv%%xdt_prj%%ti99_prj%\%ti99_img%
%xdt_drv%
cd %xdt_prj%%ti99_prj%
%xdt_as% -R -S -I %xdt_drv%%xdt_lib% -i %ti99_src%
goto loop

rem ***************************************************************************

:disk
echo (D)isk for MAME
echo %xdt_drv%%xdt_prj%%ti99_dsk%
%xdt_drv%
cd %xdt_prj%
%xdt_dm% -X 2s2d40t %ti99_dsk%
%xdt_dm% %ti99_dsk% -a %xdt_drv%%xdt_prj%%ti99_prj%\%ti99_src% -n %dsk_asm% -f DIS/VAR80
%xdt_dm% %ti99_dsk% -a %xdt_drv%%xdt_prj%%ti99_prj%\%ti99_obj% -n %dsk_obj% -f DIS/FIX80
%xdt_dm% %ti99_dsk% -a %xdt_drv%%xdt_prj%%ti99_prj%\%ti99_lst% -n %dsk_lst% -f DIS/VAR80
%xdt_dm% %ti99_dsk% -a %xdt_drv%%xdt_prj%%ti99_prj%\%ti99_img% -n %dsk_img% -f P
%xdt_dm% %ti99_dsk%
goto loop

rem ***************************************************************************

:showsettings
cls
echo (S)ettings in use
echo.
echo xdt:
echo   xdt       : %xdt_drv%%xdt_dir%
echo   Assembler : %xdt_as%
echo   Diskmgr.  : %xdt_dm%
echo.
echo Project:
echo   Project   : -''- \%ti99_prj%\
echo   Source    : %ti99_src%
echo.
echo Externals:
echo   Editor    : %xdt_ed%
goto loop

rem ***************************************************************************

:emulator
echo e(M)ulate  %emu_drv%%emu_dir%%emu_bin%
echo.
copy %xdt_drv%%xdt_prj%%ti99_dsk% E:\Spiele\MAME\TI99\disk\%ti99_dsk%
%emu_drv%
cd %emu_dir%
%emu_bin% %emu_par% -flop2 TI99/disk/%ti99_dsk%
goto loop

rem ***************************************************************************

:quit
echo (Q)uit
%wrk_drv%
cd %wrk_dir%
set ti99_prj=
set ti99_src=
set ti99_obj=
set ti99_lst=
set ti99_img=
set ti99_rpk=
set ti99_dsk=
set dsk_asm=
set dsk_obj=
set dsk_lst=
set dsk_img=
set xdt_drv=
set xdt_dir=
set xdt_prj=
set xdt_lib=
set xdt_as=
set xdt_ed=
set xdt_dm=
set wrk_drv=
set wrk_dir=
set emu_drv=
set emu_dir=
set emu_bin=
set emu_par=
echo done...
goto ende

:TOUPPERCASE
if not defined %~1 exit /b
for %%a in ("a=A" "b=B" "c=C" "d=D" "e=E" "f=F" "g=G" "h=H" "i=I" "j=J" "k=K" "l=L" "m=M" "n=N" "o=O" "p=P" "q=Q" "r=R" "s=S" "t=T" "u=U" "v=V" "w=W" "x=X" "y=Y" "z=Z" "ä=Ä" "ö=Ö" "ü=Ü") do (
call set %~1=%%%~1:%%~a%%
)

:ende

 

[Michael Rittweger]

The usage of this batch is
* xdt99 <project> [<source>]
while <source> must not have an extension.

 

The batch then initializes a lot of constants, some of them depending on the one or two parameters given.

If you have a look at chapters (labels) param1 and param2:
* If param1 <project> is not given then the batch ends instantly. Otherwise the %1 is stored in <ti99_prj>.
* if param2 is not given then <project> is used as a base for the filenames <ti99_wrk>. Otherwise %2 is stored there.

 

From <ti99_wrk> there are derived a few filenames for source, object, list, image, rpk and disk files.

Given that you may have a project folder like "graphics" and work on a specific source "grf1.a99" within that folder by calling the batch with:
* xdt99 graphics grf1
I would recommend to not use more than 6 letters for the source and not more than 10 letters for the project. Reason: I normally use the filename same as the "start" label and the project name is used as the disk-label (not the filename, but the label for the TI filesystem).

 

Now the interesting part you have to adapt - chapter "settings":

A lot of "set=..." for setting up the working directory / files (wrk), incorporating the cross-assembler and other external tools (xdt), the emulator (emu) and the like. This is the place where you will have to adapt one or another path and bin name.

 

As you can see, the "windows" filenames are directly derived from <ti99_wrk> by adding .a99, .obj etc to the base. The "ti99" filenames are derived from the (uppercase) <ti99_wrk> by adding A, O etc. I normally separate file infos into <drive>, <path> and <file> to make moving the directory to another drive a bit easier.

 

And then there is the big <emu> chapter that sets up the emulator, MAME in this case. Please note that there is set up a <flop1> with the disk for the Editor/Assembler and that <flop2> is REMed out - that one will be set later on.

 

There are 4 loops following that you simply can ignore. They are a test for the project / file separation and I just happen to have them not deleted before publishing. What I will try to get: Albeit working on a specific source right now the (D)isk command shall copy other files from that "project" to the created disk, too. So if the project "graphics" contains grf1, grf2, grf3 and vdptools they all should be copied later on.

 

The lifetime cycle of the batch starts at chapter "loop". After getting the user's choice it branches to the chosen chapter and hopefully executes the wanted tasks by using all that set up variables.

 

(E)dit starts the external editor. I'm quite happy with NotePad++ although the syntax highlighting is not perfect. That d**n asteriks and greater-than characters always mix up with remarks, formulas and the like. Perhaps I have to always use ** for remarks and use blanks after the > operator to help with NP recognize them correctly.

 

Nevertheless... If you start the (E)ditor the batch will wait for return from there, if... If you already have the editor opened then it will return instantly. I use this quite often to spare the (E) and work directly in the editor, save the file and continue directly with the (A)ssemble.

 

For completeness I usually start creating (R)pk and (I)mage, too. Then The (D)isk has to be created and finally the e(M)ulator can be started.

 

From the TI title screen a keypress leads to the menu where Editor/Assembler should be an option if nothing went wrong mounting the cartridge.

From EA via option 3 "load and run" the compiled object code is found as DSK2.<ti99_obj> if nothing went wrong mounting the disk, too. If you are unsure about the exact filename just have a look at the last output from the batch: xdt shows the current directory of the disk.

 

Have fun...

 

[Michael Rittweger]

Ah, and I should have added:

 

The <project> folder must be created prior to calling the batch! Have a look at

set xdt_drv=E:

set xdt_dir=\Spiele\MAME\TI99\xdt99\

set xdt_prj=%xdt_dir%projects\

 

So I would have to MKDIR a project folder like

E:\Spiele\MAME\TI99\xdt99\projects\graphics

Probably a

rem. > grf1.a99

in there, too, to create an empty source file. But that depends a bit on the editor used - how it complains about the "not existing" input file.

 

And I like to have that batch as

E:\Spiele\MAME\TI99\xdt99\xdt99.bat

to have the projects folder directly beneath the compiler.

 

BTW: The batch uses a "library" path for xas99 via

set xdt_lib=%xdt_dir%lib\

Just in case you didn't notice...

 

Michael

 

 

[Airshack]

I'm getting errors during the windows setup process. Any idea what's wrong? Installed Python 3.8.5.

 

The install works fine on my desktop PC yet gives this error on my laptop?

 

 

Same error appears on command prompt without administrator.

 

 

 

 

 

 

[ralphb]

@Airshack: You asked me also in PM, and answered you there.

[+Lee Stewart]

On 7/31/2020 at 2:21 AM, Airshack said:

I'm getting errors during the windows setup process. Any idea what's wrong? Installed Python 3.8.5.

 

3 hours ago, ralphb said:

@Airshack: You asked me also in PM, and answered you there.

 

So as not to break this thread, perhaps one of you could share the answer here?

 

...lee

[Airshack]

1 hour ago, Lee Stewart said:

So as not to break this thread, perhaps one of you could share the answer here?

 

...lee

I re-accomplished these steps which fixed the self-induced problem:

 

assoc .py=pythonsource
ftype pythonsource=<your python path> "%1" %*

I can't remember but I may have left the "1%" %* part off. Anyway -- fixed. Just backtracked and did everything very carefully. 

. 

Enjoying the workflow improvement over the no longer updated/supported Winasm99. I've read others encouraging the switch from Winasm99 to the xdt99 tools. Right now I'm using xas99 (assembler) along side the xdm99 (disk and file manager) via the Win10 command prompt. 

 

I was hesitant to leave the comfort of Winasm99's GUI. Why did I wait? The xdt99 Cross Development Tools offer greater capability and efficiencies. I'm especially impressed with how easy it is to simply run a simple script to automate the source assembly and object-file transfer to disk image. Super slick and actively developed. 

 

Thank you Ralph Benzinger!

 

[+Lee Stewart]

1 hour ago, Airshack said:

Enjoying the workflow improvement over the no longer updated/supported Winasm99. I've read others encouraging the switch from Winasm99 to the xdt99 tools. Right now I'm using xas99 (assembler) along side the xdm99 (disk and file manager) via the Win10 command prompt. 

 

I was hesitant to leave the comfort of Winasm99's GUI. Why did I wait? The xdt99 Cross Development Tools offer greater capability and efficiencies. I'm especially impressed with how easy it is to simply run a simple script to automate the source assembly and object-file transfer to disk image. Super slick and actively developed. 

 

Thank you Ralph Benzinger!

 

I know talk is cheap, but I really do intend to move over to Ralph’s xdt99 tools soon. Comfort is my excuse as well. Perhaps I will make the move when I get to fbForth 2.0:13, which will happen, at the very least, when I get around to making fbForth 2.0 work with >1 MiB SAMS.

 

...lee

[Airshack]

There was a nice conversation about xdt99 during the Covid/Zoom meetup this past weekend. 

 

I'm really enjoying the use of xas99 and xdm99, along with a simple batch file, to produce EA3, EA5, and .bin files for my current project.

 

The EA3 and EA5 files are working flawlessly. Unfortunately, I am unable to get a binary file generated with xas99's "-b" option to run on Classic99.

 

Ralph's Example:  

Generate binary data files, e.g., for FinalGROM cartridge:

$ xbas99.py -b <source file>

 

My resulting .bin file does appear after issuing the "-b" command -- no errors or warnings. My problem is it won't load and function as expected with Classic99's Menu: Cartridge/User/Open. C99 appears to load my .bin file yet the TI boot menu only shows "1. TI BASIC." 

 

Any quick specific tips regarding AORG setting (I have >6030 as per Ralph's instructions) and/or the mystical "GROM Header?" I don't really understand the GROM header details/concepts as I've been getting away with AORG >A000, and then just using Fred's Kaal's Module Creator to do the dirty work for me.

 

Obviously, I'd prefer to let my batch file create my binaries effortlessly using xas99.

 

 

 

 

[+jedimatt42]

1 hour ago, Airshack said:

There was a nice conversation about xdt99 during the Covid/Zoom meetup this past weekend. 

 

I'm really enjoying the use of xas99 and xdm99, along with a simple batch file, to produce EA3, EA5, and .bin files for my current project.

 

The EA3 and EA5 files are working flawlessly. Unfortunately, I am unable to get a binary file generated with xas99's "-b" option to run on Classic99.

 

Ralph's Example:  

Generate binary data files, e.g., for FinalGROM cartridge:

$ xbas99.py -b <source file>

 

My resulting .bin file does appear after issuing the "-b" command -- no errors or warnings. My problem is it won't load and function as expected with Classic99's Menu: Cartridge/User/Open. C99 appears to load my .bin file yet the TI boot menu only shows "1. TI BASIC." 

 

Any quick specific tips regarding AORG setting (I have >6030 as per Ralph's instructions) and/or the mystical "GROM Header?" I don't really understand the GROM header details/concepts as I've been getting away with AORG >A000, and then just using Fred's Kaal's Module Creator to do the dirty work for me.

 

Obviously, I'd prefer to let my batch file create my binaries effortlessly using xas99.

 

 

 

 

 

The -b option produces a 'binary' with no TI EA5 header, no TIFILES, no overhead... So it is suitable for building a loose cartridge ROM.

 

I can work up an example... but you should have AORG 6000 , and then the rom header, which is like the GROM header, but slightly different.  Be back in 30 minutes. ( I hope ) 

 

[+Lee Stewart]

1 hour ago, Airshack said:

I am unable to get a binary file generated with xas99's "-b" option to run on Classic99.

 

I do not yet know how that works with xas99, but below is the ROM header I use for fbForth 2.0, with comments that may give you some insight into some of the “magic” of the header:

        AORG >6000                  ; cartridge rom
        
* Cartridge ROM header
        
       BYTE >AA                    ; standard header
       BYTE >14                    ; version number
       BYTE >00                    ; number of programs
       BYTE >00                    ; not used
       DATA >0000                  ; pointer to power-up list
       DATA MENU                   ; pointer to program list
       DATA 0                      ; pointer to DSRL list
       DATA 0                      ; pointer to subprogram list
       
MENU   DATA MENU40                 ; pointer to next menu item
       DATA STRT80                 ; code entry point 
       BYTE 17                     ; length of text
       TEXT 'FBFORTH 80 COLUMN'
       EVEN
MENU40 DATA 0                      ; no more menu entries
       DATA STRT40                 ; code entry point 
       BYTE 14                     ; length of text
MTEXT  TEXT 'FBFORTH 2.0:12'
       EVEN

 

...lee

[+jedimatt42]

Thanks @Lee Stewart, saved me some spec reading.

 

Given a source file: cart.a99, the following xas99.py command will turn it into a bin that classic99 loads:

 

xas99.py -b -R -L cart.lst -o cart_c.bin cart.a99

 

The contents of cart.a99 are:

 

        AORG >6000				; cart roms headers start here

        BYTE    >AA             ; Standard Header
        BYTE    >01             ; version
        DATA    >0000           ; # of application programs / reserved
        DATA    >0000           ; power up list - not used in cart ROM
        DATA    menu1           ; user-program list (cart only)
        DATA    >0000           ; dsr list ( not used in cart ROM )
        DATA    >0000           ; LVL2 DSRLNK & BASIC CALL subroutine list ( not used in cart ROM )

menu1:
        DATA    >0000           ; next menu item address
        DATA    prog            ; program address
        BYTE    9               ; len of menu title
        TEXT    'AIR SHACK'     ; title of cartridge
        EVEN                    ; this already is even, but best to stay out of trouble

prog:
        blwp    @>0000          ; reset the console - very small program

 

This is a super simple program that resets the console.. you can set the breakpoint in the debugger to 601A and see it... 

 

Here is the listing output, if we add the -L cart.lst option to the xas99.py command... 

 

AS99 CROSS-ASSEMBLER   VERSION 3.0.0
     **** ****     > cart.a99
0001               ; DSR ROM header
0002                    AORG >6000
0003
0004 6000 AA            BYTE    >AA             ; Standard Header
0005 6001   01             BYTE >01             ; version
0006 6002 0000             DATA >0000           ; # of application programs / reserved
0007 6004 0000             DATA >0000           ; power up list - not used in cart ROM
0008 6006 600C          DATA    menu1           ; user-program list (grom only)
0009 6008 0000          DATA    >0000           ; dsr list ( not used in cart ROM )
0010 600A 0000          DATA    >0000           ; LVL2 DSRLNK & BASIC CALL subroutine list ( not used in cart ROM )
0011
0012               menu1:
0013 600C 0000             DATA    >0000                ; next menu item address
0014 600E 601A             DATA    prog         ; program address
0015 6010 09            BYTE    9               ; len of menu title
0016 6011   41             TEXT    'AIR SHACK'     ; title of cartridge
     6012 4952
     6014 2053
     6016 4841
     6018 434B
0017
0018               prog:
0019 601A 0420  54         blwp @>0000          ; reset the console - very small program
     601C 0000
0020

 

You can see I got the breakpoint address from that second column, that shows the address of the blwp instruction. 

Also if you look at the parameter of the DATA prog  statement, you see that prog is that address... 

 

The listing is extremely useful for debugging, so you can find those breakpoints.. 

 

The header can be confusing when you just want to make a ROM cartridge. This is because TI used the same header layout for DSR ROMs on expansion boards, and GROM, as it did for CART ROMs... But only some fields make sense in some contexts... 

 

[+jedimatt42]

And actually looking at Lee's example, you don't need the header parts I have starting with interrupt list, and the cartridge port doesn't service interrupts... So I will revise that post.

 

 

[Tursi]

When you only got the TI BASIC screen, you should first check the debug log to see if it recognized the cartridge type correctly. Since you didn't mention how you were loading it, I assume "auto-guess", and if you don't provide the final tag character in the filename (in this case it probably should end with "c.bin" for an 8k cart), all bets are off.

 

It's every bit as likely Classic99 doesn't know how to load it as the header is off.

 

If the debug log suggests it detected and loaded correctly, the next step is to use the debugger, look at address >6000, and see if it's appearing correctly there.

 

[ralphb]

To round it off, if you already have an AORG >6030 in your code, you can use -c instead of -b to create a MAME cartridge.  If you unzip the .rpk file, just use the file that is NOT layout.xml or meta-inf.xml for Classic 99.  EDIT: I guess there are some bank mappings that don't work for Classic 99, but if you only have 1 bank you should be fine.

 

The option -c will generate this GPL header automatically, and also create an .rpk archive for MESS.

 

I suggest using -b, though, as it is more flexible.

Edited August 5, 2020 by ralphb

[Airshack]

16 hours ago, Tursi said:

When you only got the TI BASIC screen, you should first check the debug log to see if it recognized the cartridge type correctly. Since you didn't mention how you were loading it, I assume "auto-guess", and if you don't provide the final tag character in the filename (in this case it probably should end with "c.bin" for an 8k cart), all bets are off.

 

It's every bit as likely Classic99 doesn't know how to load it as the header is off.

 

If the debug log suggests it detected and loaded correctly, the next step is to use the debugger, look at address >6000, and see if it's appearing correctly there.

 

 

I was attempting to load the .bin file via: C99/cartridge/user/open 

 

As for the debug log...that’s something I’ll need to learn. I am guilty of not following step-1: RTFM, in this case. I’m certain I’m underutilizing the debug tooLs in Classic99. 

 

Final tag character? STRIKE TWO! I left that out as well. In the past I’ve read your posts where you reminded others to do this but until this very moment I wasn’t listening. Patience appreciated. I will explore this avenue.

 

”Auto-Guess.” Lol. Hoping this feature improves in future versions of Classic99. 

 

I’ll check >6000 with the debugger and report back on the debug log. Thank you.

 

 

 

 

 

 

[Airshack]

13 hours ago, ralphb said:

To round it off, if you already have an AORG >6030 in your code, you can use -c instead of -b to create a MAME cartridge.  If you unzip the .rpk file, just use the file that is NOT layout.xml or meta-inf.xml for Classic 99.  EDIT: I guess there are some bank mappings that don't work for Classic 99, but if you only have 1 bank you should be fine.

 

The option -c will generate this GPL header automatically, and also create an .rpk archive for MESS.

 

I suggest using -b, though, as it is more flexible.

I have >6030 as per Ralph’s instructions...which I’ve actually read.

 

The MAME cartridge .rpk  was something I assumed was completely exclusive to MAME. That’s good news that it produces a bin file usable elsewhere, specifically Classic99. This is did not know.

 

No bank mapping knowledge here so just one bank. 

 

I’ve been attempting cart generation with the -b in an effort to avoid the MAME rabbit hole for now. 

 

Thanks Matt!

 

 

 

[Tursi]

3 hours ago, Airshack said:

”Auto-Guess.” Lol. Hoping this feature improves in future versions of Classic99. 

How do you propose it be improved?

 

Short or trying to determine whether there is a cartridge header, WHERE the cartridge header is, whether it's the FIRST cartridge header, and then trying to interpret the executable bytes to see if they are 9900 or GPL -- all of which is tricky and/or error prone -- I have no ideas how to improve it.

 

It's meant to simplify the loading of carts that you already know what they are, and you tell the emulator. Making it guess is never going to work 100%.

 

As a human, there are few things we can look for that help us guess, like the addresses in the header, but ultimately, we have to try it and see if it's right. If it's wrong, we try "the other way". That's another tricky thing for the emulator to do.

 

Instead of me spending hours on the problem, and then countless more on all the bug reports, just tag your files. It's ONE CHARACTER. It's been a system that has worked well for 30 years and also means when someone finds your file in an archive 30 years from now, they KNOW WHAT IT IS. 

 

[Airshack]

7 hours ago, Tursi said:

How do you propose it be improved?

    Uh oh Mike — yikes! My suggestion to improve “Auto-Guess” was based on the belief that you were joking about the existence of such a feature. As in, “the emulator does not have auto-guess <insert snicker>, so you need to tag your files.”  Most certainly I will tag my files as it’s no big deal. I just forgot about tagging them as it has been a while since I read about it. 

 

   The many hours/years you have spent on developing Classic99...greatly appreciated. This emulator has provided so much learning and enjoyment that I can not begin to thank you enough. Hopefully you’ll need not “auto guess” my appreciation for your feedback as well. 

 

   I am well aware that my lack of expertise in this arena puts me in no position to suggest improvements to your excellent and selfless work. Admittedly, I wouldn’t know where to begin.

[Airshack]

On 8/5/2020 at 6:57 AM, ralphb said:

To round it off, if you already have an AORG >6030 in your code, you can use -c instead of -b to create a MAME cartridge.  If you unzip the .rpk file, just use the file that is NOT layout.xml or meta-inf.xml for Classic 99.  EDIT: I guess there are some bank mappings that don't work for Classic 99, but if you only have 1 bank you should be fine.

 

The option -c will generate this GPL header automatically, and also create an .rpk archive for MESS.

 

I suggest using -b, though, as it is more flexible.

I do already have AORG >6030 in my code.

 

   The -c route was attempted in order to create MAME cartridge. After researching .rpk files I discovered they’re essentially zip files which contain all dumps along with the information required to set up the cartridge in emulation. 

 

   Next I renamed the .rpk file to .zip file and unpacked it using right-click/extract all under Win10. As you said, there were a few files extracted: program.bin, layout.xml, meta-inf.xml.

 

   Dump: program.bin

   Cart setup files: layout.xml, meta-inf.xml

 

   The resulting program.bin would not load via: Classic99 dropdown menu/Cartridge/User/Open/program.bin

     — by “not loading” I mean only “1. TI BASIC” appears, no option 2. Program

 

   After tagging/renaming the program.bin to PROGc.bin it appears to load, as there now is an option “2. PROG.”

 

   When I select option 2 there’s simply a light blue screen of death — hang.

 

   Classic99 Debugger with radio button GROM selected, and 6000 in the window, all zeros at >6000 and above.

 

   So we have a menu item showing up yet no loading of the .bin. 

 

   

[ralphb]

I don't know what is wrong here yet, but the Debugger should be set to ROM, not GROM.

[RXB]

I think AUTO GUESS can be built in, but believe me it is not easy to do.

In RXB I have CALL CAT("DSK2.") or CALL DIR("DSK2.")

That is pretty standard and not new in the least but I got the idea to make RXB smarter then everyone else.

So...

CALL CAT(2) is the same as CALL CAT("DSK2.") easy so why not expand on this right?

How about CALL CAT(A) would be same as CALL CAT("DSKA.") or X$="DSKA." :: CALL CAT(X$)

Why not even smarter CALL CAT(65)  as that is the ASCII value for A so now to catalog a RAMDISK could be:

CALL CAT(character 1 to 9 or A to Z) = DSK1 to DSK9 or DSKA to DSKZ 

Or you can CALL CAT(49) is the ASCI value for 1 thus same as CALL CAT(1) or CALL CAT("DSK1.")

CALL CAT(string-variable or numeric-variable) = Y$ string variable with "DSK2." in that string or X a numeric variable with 2 in it.

 

Now how about adding in multiple catalogs:

CALL CAT(1,2,3,4) this would catalog disks 1 to 4 and SPACE BAR would pause any of them as it runs.

 

Now we have a pretty close to AUTO GUESS Catalog routine.

 

 

Edited August 6, 2020 by RXB
additional text