Classic99 Updates

[Tursi]

Yeah it was cool. Here's a technique that might work better, but it would require a hack to classic99 which you may consider to be cheating :-)

 

Intercept writes to the interrupt vector such that they get added to a stack of interrupt vectors. With each interrupt you work through the stack caking the intended routine then call your own routine before returning from the interrupt.

 

You might not need a stack at all. After all, most applications will only install one interrupt routine. Just a location in memory to hold the intended vector.

 

Good fun :-)

This was intended to run on real iron, so hacking a single emulator wouldn't do. If that was legal, I would have just hacked the console ROM to display my banner itself.

[+Vorticon]

Tursi, would it be possible to add a virtual serial port capture feature in Classic 99 in the future? By that I mean if a program running within Classic 99 sends data out to the serial port, Classic 99 would capture it in some kind of log file. The program itself would not know the difference. This would be tremendously helpful for the UCSD Pascal environment.

[RXB]

Yea would love to use my USB to SERIAL cable I bought using Classic99

[Shift838]

Yea would love to use my USB to SERIAL cable I bought using Classic99

 

yes. that would be cool.

[Tursi]

Tursi, would it be possible to add a virtual serial port capture feature in Classic 99 in the future? By that I mean if a program running within Classic 99 sends data out to the serial port, Classic 99 would capture it in some kind of log file. The program itself would not know the difference. This would be tremendously helpful for the UCSD Pascal environment.

Yes, it's on my list, I want to get the Serial/PIO support done and have a means of selecting various attached devices. I actually started writing an Epson printer emulator so I could print to the Windows system, but I got bogged down there. (Does one already exist anywhere I could integrate?)

[globeron]

Yes, it's on my list, I want to get the Serial/PIO support done and have a means of selecting various attached devices. I actually started writing an Epson printer emulator so I could print to the Windows system, but I got bogged down there. (Does one already exist anywhere I could integrate?)

 

Not sure, but I read somewhere that Michael Zapf had one and also V9T9 has one extra file (not on the repository) rs232pio.bin to print to the screen. And Ti99w (of Fred Kaal),

I remember I have been using RS232 serial interfaces in those systems (not sure if the source code is available somewhere on github ? )

[Davvel]

I did a little utility program tonight that can send paste strings to Classic99 from the command line (as well as reset it), so that you can use it in Makefiles to automatically load your programs.

 

It's called classic99paste, but if you look at the included source, it's really simple. It just finds the Classic99 window and sends it a couple of window commands.

 

Usage is really simple. First, launch Classic99, and make sure it's configured for the module you want. For this test, pop into TI BASIC first, then in a command prompt somewhere, run:

 

classic99paste 10 REM Hello this is a paste string\n

It supports two switches, if you pass "-reset", it will reset the emulator before running the string. If you pass "-resetOD", it will reset the emulator AND set CPU Overdrive before running the string.

 

I'm using it at the end of a GCC makefile. The end of my makefile looks like this:

 

$(CP) GROMCF* /cygdrive/c/classic99/dsk1/
	/cygdrive/c/work/classic99paste/release/classic99paste -reset "xx25DSK1.GROMCFG\n"

The CP command invokes the copy command to copy the output EA#5 files into Classic99's DSK1 folder (I'm using Cygwin, that's why the 'cygdrive' syntax). And the classic99paste runs. That string first resets the emulator, then presses 'xx' (to pass the master title screen - one key gets eaten by the system), '2' to select Editor/Assembler (which I pre-configured), '5' to select 'RUN PROGRAM FILE', and DSK1.GROMCFG and an enter key to start it up. I have to use quotes in Cygwin otherwise it drops the backslash (Windows doesn't do that).

 

Hope someone finds it useful.

 

classic99paste.zip

 

Tursi, trying this utility in windows 10 is giving me some issues. Once I call it to push some text towards CLASSIC99, it keeps sending the same text no matter what I send afterwards, except -reset.

 

Therefore if I send say "hello" (classic99paste hello) whilst I am in TI BASIC, then hello is displayed, but if I write classic99paste 123 or anything else it keeps emitting hello, If I send -reset it resets TI99 and then anything I send after that becomes hello.

 

Once I restart my laptop I can send something new, for example "bye" but then I am stuck with bye.

 

Thanks

 

David

[Tursi]

Roger, I'll take a look. I think I noticed issues with it recently myself.

[1980gamer]

Does a way exist to display the line number being executed in basic or xb?

Not using trace of course....

 

Something like display at(1,1):peek xxxxx

 

or can the emulator do this? I don't understand the heat map etc. I am certain, good debugging tools are available that I am not using.

Watching variables would be great!

 

I do this on the screen a lot, but, then I need to clean up and some of the time I'll have a goto or gosub that will not work after deleting the display lines...

Not a big deal early in the process, but when I get to 500-600 lines, it becomes a little bit more of an issue.

 

Thanks

Edited July 10, 2016 by 1980gamer

[Tursi]

The debugger isn't intended for debugging high level languages like XB. I am not sure what address contains the current line number.

[RXB]

For XB you want:

SMART PROGRAMMER

Volume 2 Issue 2

August 1986

 

This has all the address and what they do in XB.

[+InsaneMultitasker]

The Smart Programmer series contains quite a lot of good information like this. Great reminder, Rich!

[+jedimatt42]

I haven't found any option for this yet in the manual or menu... Is it possible to disable the SAMS and 32K expansion leaving just 16bit pad, and VDP ram?

 

I want to write a memory test that doesn't operate out of the RAM, and only tests it... I'd like to be able to run it with no memory expansion available. Or is there another technique with classic99 that can help me validate that I'm not using expansion ram? I guess the debugger with the CPU memory shown...

 

Or can I use the .ini to create 'ROM' in the 2000 and A000 spaces?

Take, 8K of zeros, and load them repeatedly:

[userCart0]

name=Frozen RAM

rom0=C|2000|2000|MODS\zerobytes.bin

rom1=C|A000|2000|MODS\zerobytes.bin

rom2=C|C000|2000|MODS\zerobytes.bin

rom3=C|E000|2000|MODS\zerobytes.bin

 

Would that flag the spaces as read only? ( Inferring from the complementary type 'R' which says it does not flag as read only )

 

-M@

[+jedimatt42]

I haven't found any option for this yet in the manual or menu... Is it possible to disable the SAMS and 32K expansion leaving just 16bit pad, and VDP ram?

 

I want to write a memory test that doesn't operate out of the RAM, and only tests it... I'd like to be able to run it with no memory expansion available. Or is there another technique with classic99 that can help me validate that I'm not using expansion ram? I guess the debugger with the CPU memory shown...

 

Or can I use the .ini to create 'ROM' in the 2000 and A000 spaces?

Take, 8K of zeros, and load them repeatedly:

[userCart0]

name=Frozen RAM

rom0=C|2000|2000|MODS\zerobytes.bin

rom1=C|A000|2000|MODS\zerobytes.bin

rom2=C|C000|2000|MODS\zerobytes.bin

rom3=C|E000|2000|MODS\zerobytes.bin

 

Would that flag the spaces as read only? ( Inferring from the complementary type 'R' which says it does not flag as read only )

 

-M@

 

Ok, after I thought about it, I just tested it. The later solution works. So If I'm building something to run out of cart ROM, I would add that as rom4=C|6000|2000|MODS\mynoise.bin. Using the cart menu to load just my bin will release the read-only lock on the RAM, unless they are all loaded together

 

Crazy flexible...

 

-M@

[Tursi]

Correct, hehe. There's no way to disable the memory expansion, but loading ROM overtop of it will have the same effect.

[RXB]

I haven't found any option for this yet in the manual or menu... Is it possible to disable the SAMS and 32K expansion leaving just 16bit pad, and VDP ram?

 

I want to write a memory test that doesn't operate out of the RAM, and only tests it... I'd like to be able to run it with no memory expansion available. Or is there another technique with classic99 that can help me validate that I'm not using expansion ram? I guess the debugger with the CPU memory shown...

 

Or can I use the .ini to create 'ROM' in the 2000 and A000 spaces?

Take, 8K of zeros, and load them repeatedly:

[userCart0]

name=Frozen RAM

rom0=C|2000|2000|MODS\zerobytes.bin

rom1=C|A000|2000|MODS\zerobytes.bin

rom2=C|C000|2000|MODS\zerobytes.bin

rom3=C|E000|2000|MODS\zerobytes.bin

 

Would that flag the spaces as read only? ( Inferring from the complementary type 'R' which says it does not flag as read only )

 

-M@

With RXB you can write a CALL EXECUTE program that runs from Scratch pad RAM, of course it can not return to XB but it could do a EXIT to restart the TI Menu.

 

I wrote the RXB game IN THE DARK and all the data you need to make a CALL EXECUTE routine to run from SCRATCH PAD RAM is there or you can run it from any address.

(IN THE DARK runs a Assembly in RAM right behind the area as XB program space.)

Assemby Speedup.zip

Edited September 15, 2016 by RXB

[+jedimatt42]

Can a custom DSR be loaded into Classic99?

 

The manual suggests, to the best of my ability to interpret, that I do something like:

 

[userCart1]

name="dsrtest"

rom0=D|4000|1000|MODS\DSR.bin

 

I would have expected to have to associate a CRU address to the entry, and would have figured given the description of a bank one and bank two, that the address and image size is ignored...

 

-M@

[+jedimatt42]

Can a custom DSR be loaded into Classic99?

 

The manual suggests, to the best of my ability to interpret, that I do something like:

 

[userCart1]

name="dsrtest"

rom0=D|4000|1000|MODS\DSR.bin

 

I would have expected to have to associate a CRU address to the entry, and would have figured given the description of a bank one and bank two, that the address and image size is ignored...

 

-M@

 

 

Ok, That works! I was having a different problem because I was linking the assembly into >6000 instead of >4000...

 

-M@

[Tursi]

Cool! I haven't tested that for a /really/ long time, nice to hear it worked for you

 

That said.. the arguments are not start address and size for type DSR (at least they aren't supposed to be)... the first one is the CRU base you want, the second is still the size. The base address for a DSR is always >4000.

 

It may have worked for you because the load code ignores all but the second nibble of the CRU address, so >4000 would have been read the same as >1000. I should probably range check that so it's more obvious.

[speccery]

That is a great feature to be able to easily load DSR's as my intention is to add the support of SD cards.

Regarding the CRU base - I assume only 1 bit is used here, to enable the DSR ROM as classic99 cannot know about custom hardware? I image that I'd need to write an add on to classic99 if I want to emulate the SD card interface.

[Tursi]

That is a great feature to be able to easily load DSR's as my intention is to add the support of SD cards.

Regarding the CRU base - I assume only 1 bit is used here, to enable the DSR ROM as classic99 cannot know about custom hardware? I image that I'd need to write an add on to classic99 if I want to emulate the SD card interface.

That's correct... the farthest you can get with the emulator itself is stepping into the ROM and seeing what the code does, there's no way to simulate unimplemented hardware. It uses the TI standard of using the first CRU bit to bank in the ROM (you have to if it's a DSR, otherwise nothing can find it.)

 

If you did create something, I'd just ask that it live in its own file and, as much as possible, don't reach too much into the guts of the emulator. I've got a lot of refactoring to do and too many assumptions may break with future code.

 

It's questionable whether I'd ship an SD card interface, since my goal was never support of every file system out there... but I'd certainly help you get it working for the purpose of debugging code. (I'm already a bit torn with the fact that CF7 and HFE are complicating the interwork with real systems ). It'd be nice if a new device didn't introduce yet another file system. But I speak selfishly there!

[Omega-TI]

(I'm already a bit torn with the fact that CF7 and HFE are complicating the interwork with real systems ). It'd be nice if a new device didn't introduce yet another file system. But I speak selfishly there!

 

I agree, I've been thinking about this myself lately. Things could get complicated and messy down the road a few years with multiple formats being used for public archival use. I believe the two standards we already have (DSK & FIAD) work well and can keep things simple. Anyone who has a CF7, NanoPEB or an HxC could easily make the conversions themselves for their own personal use with TI99Dir or that other program (the name of which escapes me at the moment).

 

If users of these devices devoted a dedicated thread for these formats, (like the FlashROM 99 thread does), without the expectation of them being put on WHTECH or any other sites, I suppose that would work too, but I cannot see why every new or existing update of a program should be forced to support anything other than the original formats.

[Airshack]

 

I agree, I've been thinking about this myself lately. Things could get complicated and messy down the road a few years with multiple formats being used for public archival use. I believe the two standards we already have (DSK & FIAD) work well and can keep things simple. Anyone who has a CF7, NanoPEB or an HxC could easily make the conversions themselves for their own personal use with TI99Dir or that other program (the name of which escapes me at the moment).

 

If users of these devices devoted a dedicated thread for these formats, (like the FlashROM 99 thread does), without the expectation of them being put on WHTECH or any other sites, I suppose that would work too, but I cannot see why every new or existing update of a program should be forced to support anything other than the original format

 

Hey Omega!

 

I'm going to test this part out tomorrow -- "Anyone who has a CF7, NanoPEB or an HxC could easily make the conversions themselves for their own personal use with TI99Dir or that other program (the name of which escapes me at the moment)"

 

Shortly after getting back into the TI-99/4 scene I purchased the HxC in order to get programs from the Classic99 onto the TI real metal. I'm going to give TI99Dir a try. What I really wish I could do is drop and drag Classic99 files into an HFE on one of my SD cards.

 

​What I'm imagining... and it does seem like a potential royal pain. Imagining the following process:

 

a. Save code written in Classic99

b. Use E/A to convert code to .BIN

c. Use "easily TI99Dir to convert .BIN to .HFE.

 

Tell me I'm wrong and there's an easier way? Please! Wouldn't it be convienient to have .HFE export capability built into Classic99?

 

PS - I LOVE Classic99! I'm really enjoy using Harry's XB256 and compiling my basic code with his basic compiler. TidbIT is an amazing tool as it has significantly improved the process of writing BASIC code for the TI. These tools blow me away and far exceed anything I ever expected to find upon returning to the world of our Lovable Lubbock Legend. It's all quite cool!

 

Seriously though, for the non-computer professional there's a fairly significant learning curve. Example: I have TIdbIT working via the web yet I can't quite get it working locally on my own PC system???

 

Soon I'll tackle the RS-232 to PC connection via Lantronics challenge. It too seems like a lot of work for the newbs. These things are all documented yet I'm left feeling like we need some new guys (maybe me) to write "...for Dummys," guides for the less entrenched and zealous.

 

 

 

 

[Omega-TI]

It sounds like what you need is the HDX modification (if you have a TI RS-232 card). You would just copy the files straight to the HxC. In fact the TI and Classic 99 can share a directory. I have a blog entry that covers a little bit of it already.

Thanks for reminding me, I need to make a DECENT video on this subject.

[speccery]

If you did create something, I'd just ask that it live in its own file and, as much as possible, don't reach too much into the guts of the emulator. I've got a lot of refactoring to do and too many assumptions may break with future code.

 

It's questionable whether I'd ship an SD card interface, since my goal was never support of every file system out there... but I'd certainly help you get it working for the purpose of debugging code. (I'm already a bit torn with the fact that CF7 and HFE are complicating the interwork with real systems ). It'd be nice if a new device didn't introduce yet another file system. But I speak selfishly there!

 

 

Thanks for your comments. I am just wondering how I should go about writing the DSR for the SD card. I think I will for sure need some means of debugging (as in breakpoints, single stepping, memory viewing). I could build those things into the hardware too, basically single stepping would be done by issuing non-maskable interrupts on instruction fetches. But that would imply a whole lot more coding.

 

I am not thinking that if I do something it would be a part of classic99, I am just trying to figure out the quickest path to DSR development. Since I know almost nothing about them yet, I am probably anyway going to start with box standard classic99 and just looking at how the file transactions arrive at normal disk DSR routines.