Tursi

Yes, Classic99 has a 32MB AMS that was added on request, but I still haven't got around to fixing the configuration so you can set it to anything else (AMSTEST bombs on out it as a result). It's encouraging to hear that code works with the test programs for the actual cards that starting to appear.

Yes, Classic99 has a 32MB AMS that was added on request, but I still haven't got around to fixing the configuration so you can set it to anything else (AMSTEST bombs on out it as a result). It's encouraging to hear that code works with the test programs for the actual cards that starting to appear.

Classic99 does have a check already for GPLWS on DSR entry. I wasn't sure if there were any bits in R14 (GPL Status) that needed to be set. I know you can confuse the interrupt routine with certain settings, but not sure if the DSRs care on entry...?

Done, thanks for sharing the result! It'll be a while before I can push any changes, though... my local internet is extremely throttled right now.

Just for my own understanding, since you're using scancodes, the keys do NOT move, only the character printed on the keycap? In that case the map image should still be valid? .. unless you are noting that the punctuation /not/ shown on the map is kind of important too. To which I say "aahhhh... yes. Right."

Bah, surely you have the keys memorized enough to be able to type blind. If not, you can always watch VDP memory in the debugger instead of looking at the screen.

Could be more than scratchpad. Most of the TI Controller bugs that hit Classic99-sourced software were VDP memory hits. Classic99 has checks for all the cases I know how to test for - you could try it there and watch the debug log.

Scratchpad loader remembers the CRU base (and DSR entry point) for loading EA#5 files after the first one, too. There wasn't enough memory in scratchpad to save all the search code

Even when using the TI keyboard mapping, those keys still move? Classic99 has the opposite problem, I thought I was honoring the local keyboard layout but the keys /don't/ move around like they should!

There's a nice keyboard map over at mainbyte.com. Scroll right to the bottom of this page: http://www.mainbyte.com/ti99/howto/classic99.html

Well, what if you reduce the 3D window to 1/4 screen like it is there? (edit) Actually, if you look at it, there's a pretty steep limit on the depth as well... if you went black earlier, you could speed distant rays.

That's pretty friggin' cool. Proper CP/M on the TI. The PI can probably do some other emulation for us too..

It's probably worth noting that if they fixed a problem you were having, the original software has what I'd consider a bug - accessing the GROMs at a non-standard base and just accepting that it happens to work. If it's new software it's worth checking for that just in case we ever release a console upgrade that actually decodes the GROM bases.

oooh, nice idea! If MAME would emulate Classic99, I wouldn't have to do anything else with it!

I usually just take an existing disk image and copy it, then use a disk manager to delete any files on it. You can also create new images in most of the PC disk management tools.

Ah, great to hear! Only tip I'd have on the old process -- you don't need to save the DSR scratchpad between DSR calls. Just backup the scratchpad once at program start, and restore it when you need to call DSRLNK (or any console services), but you don't need to back it up again afterwards. In fairness you don't even need the entire scratchpad, there's lots the console doesn't use, but it's quick enough. That would save you one copy at least.

I think the official name is "standard header", which isn't very descriptive.

I've done the "swap in scratchpad for DSRs" before too.. but, the scratchpad is only 256 bytes. Why do you need to move 1.5k /per record/? Even if you did all of scratchpad, that's 512 bytes, plus 80 bytes max for the D/V80 record? That said, certainly nothing wrong with your plan to move stuff over to regular RAM. Scratchpad really only offers a large benefit for frequently accessed data - if you only hit it now and then you'd be hard pressed to see the difference. It's only 4 cycles slower to read and 8 cycles slower to write - still faster than a single 9900 instruction.

You keep saying GPL header, but it's not a GROM, right? You just mean the Standard TI Header For Anything and Everything?

Yeah, the allocation table bitmap limits it to 400k. As far as I know, only the compact flash device uses disks that size. When it fails, open the debugger (Edit->Debugger), and read the text. Classic99 will tell you WHY it failed, that's helpful for understanding what happened, since I can't reproduce your work. If you create an empty disk in the Classic99 disk menu, you get a 180k DSSD image. It should never grow larger - and if you use file access it won't. (It's not a very good diskette emulation if it grows ). It's only the direct sector access code that isn't range checking. It's just a convenience, it's expected that people have better ways to get a disk image, if they are using them. Serial ports are very possible but Classic99 does not support them today. MESS does, though I think only through some sort of simulation and not to the physical port?

See if you can access the /last/ block on the disk... Classic99 does not intentionally extend the size of the files, it's supposed to divine the size of the disk from the file. But the disk image code was originally very flexible (like, TOO flexible), so I suppose there is a tiny chance it might work. But if there are any checks in your code path they're going to assume a maximum size of 400k. You might get lucky - if you do, I should codify it both to ensure I don't break it in the future and to ensure it does what it's supposed to do. Edit: ... well.. the image disk code doesn't do any checks and the sign/unsigned nature of the code that parses the information seems to be correct, so there's a good chance it will work... I never anticipated there would be such a system. I'm definitely going to need to make some tweaks to that code path but knowing how it is now being used is good. (Obviously these mutant floppies won't be transfer-able to another system... )

Uhhhh.... how? I'm both curious what was involved in setting that up, and concerned that the emulation might not support what you did when you actually start to fill the disk (but it might).

Yes, it's what my old one did too, but I moved my functionality into Classic99. Classic99 can also create loader carts from anything loaded into RAM (though, since you need to tell it the addresses it has turned out to be unpopular compared to the ease of an EA#5 converter )

Yeah.. technically 4 banks because the count needs to be a power of 2. Apologies, I didn't even notice the SIZE of the program (I thought you were just doing a quick proof of concept). When your ROM cartridge exceeds 8k, you have two choices. Both require bank switching, meaning you get to learn about the infamous "inverted vs non-inverted" debate... though I think we're settling on non-inverted for all but XB. Option one is to modify your program - change it so that it is divided into 8k pieces, and carefully control which 8k chunk is running at any particular time - complete with manually switching banks at the correct point. Option two is to make a "copy cart" that works more like an EA#5 loader, but from ROM. The loader copies your program from ROM to RAM, then starts it. This is plenty fast and the only real downside is the 32k requirement. We've got lots of sample code for this already. In both cases the bank switch needs to be considered carefully... since when you change banks the /entire/ 8k changes. The two main approaches to this are just making sure that the bank switch always happens at the exact same address in every bank (easy if it's the first code), or to create a "trampoline" - bank switch code that runs in the scratchpad or other RAM. The cartridge jumps to the trampoline code, the trampoline changes the bank, then "bounces" back to the ROM, but at the new address.

The pSystem emulation in all systems use disk images, because the p-System uses sector access to get at its data. The single file it creates is more to prevent people from accidentally overwriting the Pascal data, it never accesses it as a file.