Jump to content
IGNORED

v9t9 TI-99/4A emulator written in java


retroclouds

Recommended Posts

Hi folks,

 

just recently I stumbled on a new version of the v9t9 emulator, this time written in java.

There was a post on the yahoo group I can't remember.

 

Anyway, this afternoon I played around with it a bit and it has some nice features. For one it offers a savestate.

Basically you can pause the machine, save to disk and later resume the TI-99/4A.

 

It does not seem to support the new bankswitching method, so I was not able to test Pitfall!

Also had some trouble setting up disk support

 

You need to copy the ROM and GROMS of the TI-99/4A but the emulator has a nice frontend for doing ROM setup.

 

From the documentation:

 

 

It supports:

  • Built-in module database
  • TMS 9918A video
  • TMS 9919 sound
  • TMS 5220 speech
  • Disk support (files in native filesystem, sector images, track images)
  • Debugger
  • Demo playback and recording support
  • UCSD P-Code System (new!)

V9t9 also contains support for:

  • V9938 (MSX2) (new!)
  • Multiple TMS9919 ("ForTI") support (new!)
  • Experimental FORTH processor ("F99B") (new!)

 

Here's the URL: http://eswartz.github.com/emul/

 

post-16219-0-39144500-1357480513_thumb.png

 

Edited by retroclouds
Link to comment
Share on other sites

Thanks for the post (and email).

 

It does not seem to support the new bankswitching method, so I was not able to test Pitfall!

 

Wow, I wasn't aware of a Pitfall for the 99/4A.

 

V9t9 supports the usual two-bank module ROM switching method -- which is probably the "old" method.

 

V9t9 has a registry of known modules in it, to make setup easy, but there's nothing for Pitfall yet.

 

In the meantime, try registering the module ROMs with V9t9 and see if it "just works":

 

1) You can create a "modules.xml" file in one of the paths mentioned in "Search Locations" in the "Setup ROMs" dialog.

2) Add content like this (assuming the files are named as below):

 

<modules>
  <module name="Pitfall!">
 <memoryEntries>
   <bankedModuleEntry fileName="pitfallc.bin" fileName2="pitfalld.bin" />
  <gromModuleEntry fileName="pitfallg.bin" />
 </memoryEntries>
 </module>
</modules>

 

3) Then click the "Switch Modules" button again and the new entry should be in the list.

 

If indeed Pitfall does something different, then if you could provide info about Pitfall's bank-switching method (and, of course, testable versions), I'd be happy to support it.

 

Also had some trouble setting up disk support

 

Let me know what issues you had, specifically, and I can try to help. It'd be good to get feedback on usability issues or just plain bugs :)

 

V9t9 should be able to handle TIFILES or V9t9 style files in host directories, sector-based disk images, or V9t9-format track-based images. Note that I've only tested single-density disks -- never got my hands on the Corcomp controller ROMs. If you were trying that, then some work will be needed :)

Link to comment
Share on other sites

Hi Ed!

 

thanks for responding to my email and welcome to our little group here on Atariage ;)

 

The Pitfall! rom image is actually a 32K single binary file containing 4 concatenated 8K banks.

The bank-switching method used is named after Jon Guidry who made a batch of new PCB's that support ROM's up to 512K (if I'm not mistaking).

If my memory serves me right, it's a "reversed" bank-switching order.

 

Example for a 32K ROM:

 

BANK 0, write to >6006

BANK 1, write to >6004

BANK 2, write to >6002

BANK 3, write to >6000

 

You can get Pitfall! (both source code and binaries) at this thread: http://www.atariage.com/forums/topic/158467-pitfall-binaries-and-source-code/

 

You also might want to check out this thread http://www.atariage.com/forums/topic/153704-ti-994a-development-resources/

If you look at section 6 "Tutorials", I added a PDF "Building a multi-bank ROM image"

  • Like 1
Link to comment
Share on other sites

 

Quote

 

Also had some trouble setting up disk support

Let me know what issues you had, specifically, and I can try to help. It'd be good to get feedback on usability issues or just plain bugs :)

 

I had some troubles loading the disk version of Pitfall. That is, I copied the files to a directory and pointed the emulator to that directory. When trying to load using #EA5 I got disk error 0.

As a workaround I created a disk image (using TIDIR windows software, see development resources thread for details) and copied the files into the disk image.

Next I setup v9t9 to use the disk image and then it worked fine. So it might be a TIFILES headers issue? (which the binary files does not have as I generated it on my windows box and mainly used the classic99 emulator).

Link to comment
Share on other sites

The Pitfall! rom image is actually a 32K single binary file containing 4 concatenated 8K banks.

The bank-switching method used is named after Jon Guidry who made a batch of new PCB's that support ROM's up to 512K (if I'm not mistaking).

If my memory serves me right, it's a "reversed" bank-switching order.

 

So, what is this bank-switching method called? Guidry-switching? :)

 

You can get Pitfall! (both source code and binaries) at this thread: http://www.atariage....nd-source-code/

 

Thanks! I was able to make the necessary changes and get it to run from the module (this brings back memories! nice work!).

 

But the keyboard support doesn't seem to work as expected, as you found. I'll be checking the assembly to see where I'm going wrong.

 

-- Ed

Link to comment
Share on other sites

I had some troubles loading the disk version of Pitfall. That is, I copied the files to a directory and pointed the emulator to that directory. When trying to load using #EA5 I got disk error 0.

 

Hmm, it worked for me with Editor/Assembler by pointing to the pitfall directory and loading DSK1.PITFALLB.

 

Error 0 would be 'device not found'... which software do you mean when you say #EA5? (I am definitely behind the times with regard to recent retro computing.) If not E/A, then it'd be interesting to see what DSR calls it's attempting.

 

So it might be a TIFILES headers issue? (which the binary files does not have as I generated it on my windows box and mainly used the classic99 emulator).

 

Nope -- the file is in classic V9t9 format, which still works.

 

If you are still having trouble, email me the config and workspace.StandardTI994A files from the ".v9t9j" directory in your home directory, so I can see if there's anything odd going on.

Link to comment
Share on other sites

By the way here is how you enable the debugger:

 

It's mentioned that v9t9 has a debugger. How can I enable it?

First, right-click somewhere in the window to get a menu, then check the "Show Advanced Controls" item. There will be a new button bar at the bottom. Then click the "Toggle Debugging" button in the middle.

 

There are definitely usability problems with this debugger... this is because, by the time I got to this iteration of v9t9, I didn't really need to debug anymore

 

Thanks Ed!

Link to comment
Share on other sites

Ed,

 

Where can I find out more information about the F99B Forth processor? I didn't see anything on the website. I'm very interested in Forth.

 

Thanks

 

For now, there's not much info except in the source -- it's just a pet project of mine.

 

Basically, it's an invented processor whose opcodes are Forth primitives (DUP, LIT, BRANCH, etc). Most are one byte except for double-width primitives. It was a test-bed for the V9938 support.

 

The ROM is built with a Forth compiler written in Java (also buried in sources). I had tried in the early aughts to use GNU Forth's cross compiler (written in Forth!) to build a Forth ROM (for 9900), but it was a royal pain.

 

I was going to post information about how to invoke the F99B machine, but I realize I didn't include the required files in the build. Maybe I could add that at some point or mail you instructions...

 

-- Ed

Link to comment
Share on other sites

Hmm, I'm not sure. Someone did contribute support for handling German keyboards... was that you?

 

Nope just some assembly for the joystick... I'm in the USA, but we emailed a bunch back and forth - I might even have the original disks you sent me when I registered... I think those were mailed. But been so long.

Link to comment
Share on other sites

Cool! I noticed you were working on an emulator... kind of lit a fire under my butt to get some of this newer stuff out there. ;)

 

Uh oh.. am I going to have to get onto my long-neglected task list?

 

This is a long shot, but since your emulator works and mine doesn't -- did you ever run into a problem with Arc303 failing to generate compressed archives? It's the last seemingly CPU bug I have to track down in Classic99. (It's either CPU or disk.) ;)

 

Link to comment
Share on other sites

.... This is a long shot, but since your emulator works and mine doesn't ...

 

I wouldn't say that Tursi. Without classic99 neither Pitfall or any of the other projects I worked on would have been possible.

Guess that goes for Willsy's Turboforth as well.

The debugger you included in classic99 really raised the bar ;-)

 

But yeah, keep the updates coming :-D

Link to comment
Share on other sites

Guess that goes for Willsy's Turboforth as well.

 

Hell yeah. It would never have happened without classic99. The debugger is the killer-feature of classic99. Classic99 has some idiosyncracities (the way the disk drive system is emulated is the big one) but I know them and I use other emulators to test (MESS emulation of file IO is seriously excellent).

 

I'd like to see serial port support! It doesn't have to be at the DSR level, just at the CRU/UART level. But hey, I'm sure there's a wish-list a mile long for Classic99 - inevitable when it has such a long heritage!

 

Classic99 kicks ass! I have literally used it nearly everyday for at least the last four years. :thumbsup:

Link to comment
Share on other sites

I wouldn't say that Tursi. Without classic99 neither Pitfall or any of the other projects I worked on would have been possible.

 

Thanks, I appreciate that. I meant in that particular case, though. Hoping for a barely remembered "Oh, yeah.. it was something to do with the DIV instruction...." or something like that ;) Like I said, long shot.

 

Worked on the code tonight, actually, since my competition is heating up ;) So much to do though :/

 

 

  • Like 1
Link to comment
Share on other sites

Hell yeah. It would never have happened without classic99. The debugger is the killer-feature of classic99. Classic99 has some idiosyncracities (the way the disk drive system is emulated is the big one) but I know them and I use other emulators to test (MESS emulation of file IO is seriously excellent).

 

Thanks, too! Although I like to maintain that it's not that Classic99's disk support has idiosyncrases, but that Classic99 does not emulate the TI disk system. Rather, it implements a file system that doesn't physically exist yet. I've worked to ensure that file system features are all doable in reality. When (if, yes) I get my Linux interface finished, it will use much of the same code.

 

But, at the same time, I've build the disk system to be easily extendable, and proved that by adding images, Clipboard and Clock. And while initially, I had no interest at all in real disk emulation, I have to admit that even I am starting to work on things that would be nice to test against the real disk, just to be sure. I know exactly how I want to implement it. It's just hard to get time for anything lately.

 

I'd like to see serial port support! It doesn't have to be at the DSR level, just at the CRU/UART level. But hey, I'm sure there's a wish-list a mile long for Classic99 - inevitable when it has such a long heritage!

 

You said that backwards. :) DSR level support is much easier than hardware level support. But yeah, I want serial support too. It's on that crazy list.

 

Link to comment
Share on other sites

 

So, what is this bank-switching method called? Guidry-switching? :)

 

-- Ed

 

I think they've just named it the "Jon Guidry bank switching method". LOL... Tursi coined it :)

 

The nice thing is that all you have to do for emulation is manually reverse the banks if the emulator supports the method of banking up to 512K non inverted. The new 512K board will be non inverted, but one can always manually flip the 8K banks around for backward compatibility with an inverted 64K board. (So to run Pitfall in the new 512K one, we just flip the four 8K banks around and all is well in the first 32K of the 512K 49F040.)

 

 

Link to comment
Share on other sites

Hmm. I guess maybe I did say that. Though in my code I call it the 379 bank switch.

 

The option of both inverted and non-inverted is going to kill my efforts at autodetect though... ;) I'm going to call the non-inverted type '4', since it's the next '3'. (Good cause to get that XML cart format from MESS implemented and extended already...)

Link to comment
Share on other sites

Uh oh.. am I going to have to get onto my long-neglected task list?

 

This is a long shot, but since your emulator works and mine doesn't -- did you ever run into a problem with Arc303 failing to generate compressed archives? It's the last seemingly CPU bug I have to track down in Classic99. (It's either CPU or disk.) ;)

 

I vaguely remember this. IIRC, it comes down to supporting e.g. "SRC reg, >0" properly, when R0 also contains either a 0 or 16. 16 really means 16 in that case.

Link to comment
Share on other sites

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