v9t9 TI-99/4A emulator written in java

[eswartz]

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

 

Okay. I've updated V9t9 with support for Pitfall (banking + keyboard fix).

 

Like above, you'll need to make a modules.xml and add this:

 

 <module name="Pitfall">
<memoryEntries>
<bankedModuleEntry fileName="PITFALL.bin" reversed="true" />
</memoryEntries>
</module>

 

(note the "reversed" attribute lets you switch the ordering).

Edited January 9, 2013 by eswartz

[eswartz]

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.

 

Not to toot too many horns, but V9t9 supports the hardware-level disk access too. I was able to get it to comprehend the Millers Graphics encrypted disks. Only trouble is, you need a way to transfer all the tracks from the 99/4A to your PC. I think all the software I used for that is long rusted.

 

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.

 

I agree on this count. Serial support is hard. (The new V9t9 does not even pretend to support it.) No one wants to use the DSR level for it, and there are such bad bugs in the RS232 DSR interrupt handler that it's hard to tell whether it's working correctly or not. I fought serial support in the DOS V9t9 for a long time before just kind of giving up on it.

 

I've seen it said before, but three cheers to Thierry Nouspiekel for providing the info that would make either of us even consider implementing serial support

[Tursi]

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.

 

Thanks for thinking back! I've looked at my code and it's right as far as I can tell.. I'll do a little more testing to make sure it's not using SRC in the area that is causing grief. ARC303 will create the file and compress the index, but it doesn't add any data, it just exits and declares itself done. Uncompressed files do work fine.

 

Eventually I'll nail that one.

 

[Tursi]

Re: disk and serial

 

V9T9 was a big inspiration in my disk implementation.. it's the main reason Classic99 uses disk files at all. I ended up settling on TIFILES format headers mostly because, unlike in the days of DOS, nearly every legal TI character is legal on modern filesystems, so I didn't want to complicate life with the remapping and the "secret" filename buried in the file. It has worked pretty well.

 

I have image read support, but I didn't implement write support yet. That's a little scarier since I can damage data more easily than with separate files. I've also got the hooks in place to implement the real DSRs, but my long term goals need the image read/write code anyway. And I like to do things like that!

 

Serial code I have reference for, at least, since I wrote a BBS back in the day, BUT definitely very happy Thierry's page exists, because there is a lot of things I would not have attempted without his work! The community has really turned out pretty great, there are so many things that are interdependent on each other.

 

[Tursi]

Oh.. and.. sorry to spam. I was going to suggest, Ed, that you might consider using the same syntax as MESS's RPK cartridge format uses for your XML configuration. It seems to be more than suitable and my eventual hope is that one day we'll have one cartridge format, one disk format, and one file format. (There should be notes on the RPK format here somewhere... I haven't got to it myself yet so I don't have them handy. But an RPK is just the ROMs zipped together with an XML file describing them.)

 

[+retroclouds]

Oh.. and.. sorry to spam. I was going to suggest, Ed, that you might consider using the same syntax as MESS's RPK cartridge format uses for your XML configuration. It seems to be more than suitable and my eventual hope is that one day we'll have one cartridge format, one disk format, and one file format. (There should be notes on the RPK format here somewhere... I haven't got to it myself yet so I don't have them handy. But an RPK is just the ROMs zipped together with an XML file describing them.)

 

You might want to check here: http://ninerpedia.or...ulticart_system

 

And here's a shell script to automatically create the layout files: http://ninerpedia.org/index.php/Tools_for_MESS

Edited January 9, 2013 by retroclouds

[+InsaneMultitasker]

Thanks for thinking back! I've looked at my code and it's right as far as I can tell.. I'll do a little more testing to make sure it's not using SRC in the area that is causing grief. ARC303 will create the file and compress the index, but it doesn't add any data, it just exits and declares itself done. Uncompressed files do work fine.

 

Eventually I'll nail that one.

Are you sure that Archiver hasn't simply compressed the input files veeeerrrrryyyy efficiently?

Edited January 9, 2013 by InsaneMultitasker

[Tursi]

Are you sure that Archiver hasn't simply compressed the input files veeeerrrrryyyy efficiently?

 

Welll... yeah. It's using Black Hole compression. Information so dense not even the compressor can extract it again.

 

[eswartz]

Tursi, retroclouds, thanks for the info about the .rpk format. I'll look into it.

 

As for arc303, I do remember it challenged the earlier disk system emulation. This is definitely where debuggers help out. I once hacked in a feature to help in situations like this, which could be developed as follows:

 

When a certain mode was enabled, the emulator could record a circular queue of recent instructions, with actual operands and all, then at a certain point (like, when an i/o error was triggered), it would dump the queue to disk.

 

This would be preferable to what v9t9 does now, which is let you start and stop dumping this info at some point based solely on watching the screen in user time, which usually results in huge files with little context.

[Tursi]

As for arc303, I do remember it challenged the earlier disk system emulation. This is definitely where debuggers help out. I once hacked in a feature to help in situations like this, which could be developed as follows:

 

When a certain mode was enabled, the emulator could record a circular queue of recent instructions, with actual operands and all, then at a certain point (like, when an i/o error was triggered), it would dump the queue to disk.

 

This would be preferable to what v9t9 does now, which is let you start and stop dumping this info at some point based solely on watching the screen in user time, which usually results in huge files with little context.

 

Yeah.. unfortunately, no errors are ever generated in this case. Archiver believes it has completed the list of files and exits the task cleanly. Errors are easy to find compared to bad behaviour.

 

Classic99's debugger has grown a lot, largely in response to things I have needed over time. It's pretty rare anymore that I need to hack the source code (one hack I do still use sometimes is writing a system trace - that I could add to the debugger, I suppose, and breakpointing to step through the execution of a single instruction. That one I don't think I can. But the latter case is pretty rare, only when I suspect an opcode is faulty.)

 

I managed to trace through one day to find the exact branch that exits the operation, but I could not work out what the Archiver was trying to do at that point. I'll probably need to dig much deeper, although... if V9T9 records a log trace, maybe I can just compare the two. But I will try to rule out the disk system first by waiting till I have the Disk DSR emulated in there.

[+InsaneMultitasker]

Yeah.. unfortunately, no errors are ever generated in this case. Archiver believes it has completed the list of files and exits the task cleanly. Errors are easy to find compared to bad behaviour.

 

Classic99's debugger has grown a lot, largely in response to things I have needed over time. It's pretty rare anymore that I need to hack the source code (one hack I do still use sometimes is writing a system trace - that I could add to the debugger, I suppose, and breakpointing to step through the execution of a single instruction. That one I don't think I can. But the latter case is pretty rare, only when I suspect an opcode is faulty.)

 

I managed to trace through one day to find the exact branch that exits the operation, but I could not work out what the Archiver was trying to do at that point. I'll probably need to dig much deeper, although... if V9T9 records a log trace, maybe I can just compare the two. But I will try to rule out the disk system first by waiting till I have the Disk DSR emulated in there.

A wild shot... but have you (or anyone else for that matter) tried Archiver version 4? I added hard drive support to the program, primarily for unarchiving files, and made a few changes to the file IO code in the process. My guess is that nothing I changed would 'fix' the bug but it may give you another reference point. And if needed, I should have the commented disassembled/updated code around here somewhere.

[Tursi]

I'm not sure.. I think I may have tried it early on and fell back on 3 for familiarity reasons, but if I did it was definitely very early in the disk simulation's life. Worth hunting down and trying again, if I have a working and non-working case to compare it's usually pretty easy to find the bug.

[+acadiel]

I really wish we could also get Mike Wright to release his PC99 code for both of you guys to have for reference. I wonder if he'd ever do that if we offered it up as an option.

[Willsy]

I really wish we could also get Mike Wright to release his PC99 code for both of you guys to have for reference. I wonder if he'd ever do that if we offered it up as an option.

 

I'd be surprised if he did. He got very seriously pissed at the amount of piracy of his PC99 emulator; not un-reasonable since he invested literally thousands of dollars in its development, including hiring a professional C programmer to do the coding, and one other guy too IIRC. He's pretty pissed at the TI community (or at least, he was, I've never spoken to him, I'm just re-hashing old stories here) though in truth I would imagine the folk that were involved in the piracy back in the day (the software was appearing 'for the taking' on BBS systems, IIRC) are long gone. The TI community is very different now, and in my experience (selling the TF cart as a non-profit for-fun project) folk have no objection whatsoever to putting their hand in their pocket.

 

Actually, I'd happily buy PC99, but I can't run it (who can, these days?) so what's the point?

[kl99]

since there is a C version of v9t9, could it be used to create an iOs App? As far as I know i-Phone/i-Pad Apps are based on objective C.

did someone had success to run it the java-v9t9 version on an android system?

[unhuman]

since there is a C version of v9t9, could it be used to create an iOs App? As far as I know i-Phone/i-Pad Apps are based on objective C.

did someone had success to run it the java-v9t9 version on an android system?

 

Now that'd be fun...

[OX.]

Actually, I'd happily buy PC99, but I can't run it (who can, these days?) so what's the point?

 

Dosbox? Maybe if someone offered to make a windows port so he could sell it as shareware he'd be more forthcoming.

[unhuman]

Well now that's something I didn't put together. I should try to run an emulator in DosBox on my Wii... Got the keyboard and everything.

 

-H

 

Dosbox? Maybe if someone offered to make a windows port so he could sell it as shareware he'd be more forthcoming.

[Tursi]

Even if PC99 was opened up, I don't think I would look at it. There's no fun in copying other people's code and I don't want to be accused of it anyway. While Classic99 includes a few external pieces of code they are there whole. On top of that is the issue of trying to map someone else's structure to my own - what would I even be trying to solve?

 

As for "professional C programmer", well, Classic99 had a professional C programmer working on it too, thank you very much.

 

All that said, Mike Wright was good to me, giving me advice on an Extended BASIC problem and other support, and indeed the only problems I ever had with any of the PC99 team were the problems that led to me starting Classic99 in the first place. (And that was simply their reluctance to allow the code to be ported to another platform ).

 

And yeah, DOSBox works great! Hell, you could create a Windows distribution just by wrapping DOSBox around it. (Although I've never run PC99 so I can't say for 100% certain it works, but I'd be surprised if it doesn't.)

[+hloberg]

 

And yeah, DOSBox works great! Hell, you could create a Windows distribution just by wrapping DOSBox around it. (Although I've never run PC99 so I can't say for 100% certain it works, but I'd be surprised if it doesn't.)

 

PC99 works O.K. in DOSBOX. The lite version works great but the full version runs far to slow to be useful which is bad as the full version has the monitor in it.

I run PC99 fairly regularly in DOSBOX and like it but have started to move away from it because it's disk incompatibility with the V9t9 standard. There are times I need a good monitor (such as classic99 has) and it's a pain to port the files back and forth.

What I do like in PC99 is the side overlay file that you can create that generally takes the place of the little strips that used to go at the top of the keyboard. very useful for editor and writer.

Also, I agree with Tursi, It would be far easier to add the good features from PC99 to another emulator then try to modify theirs.

Which is sad as they do have a good solid product that time has just past by.

[+Vorticon]

PC99 works O.K. in DOSBOX. The lite version works great but the full version runs far to slow to be useful which is bad as the full version has the monitor in it.

I run PC99 fairly regularly in DOSBOX and like it but have started to move away from it because it's disk incompatibility with the V9t9 standard. There are times I need a good monitor (such as classic99 has) and it's a pain to port the files back and forth.

What I do like in PC99 is the side overlay file that you can create that generally takes the place of the little strips that used to go at the top of the keyboard. very useful for editor and writer.

Also, I agree with Tursi, It would be far easier to add the good features from PC99 to another emulator then try to modify theirs.

Which is sad as they do have a good solid product that time has just past by.

 

V9t9 has an excellent integrated debugger as well, although not as flexible as the Classic99 one.

[+hloberg]

V9t9 has an excellent integrated debugger as well, although not as flexible as the Classic99 one.

Funny thing, to access the monitor in V9t9 you press the SysRq button. I don't have a SysRq button on my new computer. Been trying to find a way around but the BOIS doesn't even have the key mapped so even a redirection won't work.

I started using TI994w for a monitor/debugger. One thing I really like about it is that it's monitor is split into different windows so it fits on my netbook when I'm on the go.

[Willsy]

Try the print screen key. On my keyboard, SysRq and PrtScn are the same physical key.

 

I much prefer the classic99 debugger. Start classic99, press SCROLL LOCK and then press HOME.

 

Ta da...!

[+hloberg]

Try the print screen key. On my keyboard, SysRq and PrtScn are the same physical key.

 

I much prefer the classic99 debugger. Start classic99, press SCROLL LOCK and then press HOME.

 

Ta da...!

I guess I should have said working SysRq as the key is there, it just doesn't do anything. Even wrote a program to display key codes and it came back with nothing.

Ya know, I starting to think it's a Windows issue why I can't get SysRq to acknowledge. I don't have a pure DOS machine so I can't test it. Both the desktop and the Netbook don't work. I haven't put too much effort into the problem at this point as I just use Classic99 or TI994w monitor.

Classic99 Monitor is great but its too big for my Netbook's 10" screen. TI994w's monitor is smaller and broke into sections. I'm on the road a lot so I do most my programming on the Netbook on the go. I probably should just break down and get a real laptop with a 15"+ screen.

[Tursi]

yeah, it's on the todo list to redo the Classic99 debugger as a set of frames that you can layout at will. That will also permit things like multiple memory view windows, etc. Of course, lots and lots of stuff is on my todo list. It's been a bit of evolution to that large static frame - the original debugger was written in the DOS version as 3/4s of a 640x480 screen with the top left quarter still displaying the TI display. But, even I need to flip back and forth between views sometimes, and I have a netbook for travel too.