Tursi

Doesn't have to, but that's another advantage of emulation, you can start making choices like that. Want a VDP with 64k? Or multiple pages? Easy. Want infinite sprites per line? That's already coded and is just a switch. Faster CPU? No problem. But then you're moving away from playable on real hardware. It just depends on your goals. Your flash stuff is pretty good and a lot of people are doing retro-styled flash titles. I don't think anyone would fault you doing what makes you happy!

I'd say, still plan for real hardware, and common systems, because I think many of your interested players will still want to run it on hardware. For emulation through a Windows EXE, just expect faster load time and the like. The theory of caching to RAM and using that to load to VDP faster - yeah would work fine, both on hardware and emulation. If you programmed the code cleverly, you could /detect/ the AMS, and use it as a sort of RAM disk - copying the data there on launch if it exists, and just reading from the floppy as-needed when it doesn't. That way you support all systems. But when you get to Classic99, caching to RAM really isn't any faster than reading from the emulated floppy, since the Windows file system is far faster than the emulated 9900 anyway, so you could read from floppy at the same speed as AMS (more or less) without caching under Classic99.

What's kind of cool about this part, is that projects done in this /style/ have attracted large amounts of interest. The biggest such project I know is La Mulana - http://en.wikipedia.org/wiki/La-Mulana - a game inspired by the limitations of the MSX system. But this runs on Windows and is not emulated at all. Another example of such a thing is Cave Story - http://www.miraigamer.net/cavestory/ - a Windows game coded to resemble a classic game. Or, for that matter, Mega Man 8 and Mega Man 9 -- all attempt to capture the feel of an older game, but bend the rules when they need a little more. So this project doesn't have to bend any rules at all to work (except maybe tricks like eliminating the need to swap disks ).

So far as a service goes, I'm open to negotiation with anyone. But I should be able to someday automate part of it. It remains a low priority however, there are several milestones I need to meet before it's possible.

Ah, fantastic! I didn't realize you were planning a no-chip solution. The new motherboard sounds great, too! Good work!

I was going to comment that a friend of mine, NFGMan, has a whole page of ripped Arcade fonts -- except that I couldn't figure out if you could actually DOWNLOAD them. Although most of the fonts are 8x8, they are pretty much all multi-color so adapting them to the TI, beyond the shape, may be tricky (not impossible for vertical color changes only). Still, it might be interesting as an additional resource for your work, Sometimes? http://nfggames.com/games/fontmaker/lister.php

I don't think that's really much different than I'm doing, except I'm doing it as PDF. I'll pop it up from the menu, too. A web page would take me longer to create, so I don't think I'll do that. It has screenshots, descriptions, etc. I don't know if it will be less "boring" (one of the criticisms of the text files), but I'll see if I can embed a little intrigue. What I also wanted to do, and I think I have most of that in there already, was a little history, tech spects, and photos of the actual machine. Classic99 is technically still a beta application, since all the hardware isn't done to my satisfaction. Technically it shouldn't need any docs!

There are no automated tools to do that.. I considered it with Classic99 and did a proof of concept with Owen's Lemonade Stand, but I need to do a little more work to do such a thing in general. The TI-99 world has seen very little retro interest until the last couple of years, so it's well behind many of the other communities. The last few years, though, have been amazing to see.

Bug. But unsurprising. The STEP key always used to work. It is BREAKPOINTS that will not fire when Scroll Lock is inactive. Step Over works by setting a special internal breakpoint at the return address, so when Scroll Lock is off, like other Breakpoints, it doesn't hit. Doesn't sound like reasonable behaviour. What I am probably going to do though is remove the Scroll Lock toggle and replace it with the debug window being open or not. So that should clear up that bug as well as making the behaviour a little more predictable. I do try to RTFM before posting. Just a document that explains in a little more detail about each feature (and an example) would be good enough for me. Matthew Ooooh, no, after all the hell I caught on the mailing list because nobody wants to read text files anymore, I started a full manual. Problem is that it's a lot of work and it's falling behind before it's even done.

Me backing up threads again... the cassette port is single-bit I/O -- one bit for input, one bit for output. By toggling the output bit at different rates, you can create tones, but you aren't limited to the frequencies the console uses. Likewise for input, the console actually samples the input signal. However, it's completely digital and pretty heavily filtered. There are also two switches in there - the cassette motor pins allow the TI to conduct current for two cassette drives. It's not a true output because you also have to provide input current,and polarity matters, but they are a true digital switch (I used these long ago to turn things on for me ). As for the trackball -- I used to have a Wico trackball for the Atari, which worked fine on the TI through an Atari pinout adapter. It translated the rolling into pulses on the normal up/down/left/right lines -- ie: no special encoding at the jack, it just worked like a joystick. I guess those are becoming pretty rare.

I do make extensive use of the listing file. But the listing file for relocatable code only contains offsets since the final addresses are resolved at load time. So you still have to do a lot of manual adjustments to find the locations. I did my best to cover that as well in my suggestions. Sure it is, the emulator does it all the time. The caveat is that the first instruction you start with needs to be valid, if you start on data you may get misaligned instructions. Since the 9900 has no code protection, a program can self modify, so there will be instances where you can't disassemble without execution. Also, the data for the X instruction, which becomes the actual instruction to execute, may not exist until run time. Of course these instances will be rare, but they do exist and the disassembly will be incorrect until execution if the data is set up at run time. These are probably good examples on the surface, but they won't work in my disassembly listing anyway. The disassembly only stores the address of code executed, not what the code was, so the history view will be incorrect if you use self-modifying code (or change cartridge ROM banks, for another common example). I'm not even sure if it attempts to store the result of an X instruction, I strongly doubt it. I likewise doubt that you'll find very many disassemblers out there that attempt to cope with those cases on any platform. This is sort of an academic discussion at this point - if these were cases you were actually using the debugger for, you'd have already seen that it doesn't work that way. Scroll Lock is the Classic99 debugger enable key. Has been for 15 years now. There's only been a menu option to load the debugger for 2 or 3, conversely. So the one is a little more tightly integrated than the other. But if you have Scroll Lock off, then NO breakpoints should work, not just Step Over. I've considered removing the Scroll Lock requirement for Breakpoints but this is the first indication anyone has ever given me that they aren't using it, and I didn't want people who were NOT debugging to suddenly start encountering breakpoints and having no idea why. If I remove the dependency on the key, I will probably require the debug dialog to be open instead. Scroll Lock's obscurity, as well as visible toggle nature, is the reason it was chosen. It's unlikely to interfere with normal operation. I'm surprised you aren't using the function keys to step, debug, etc, though. Those also require Scroll Lock to be active. Guess I should finish the manual so you guys don't have to suffer through a text file, eh?

I believe so... it appears to be working for me. My first question would be, is it returning /exactly/ to the next address? it looks from your sample like it should, but if you increment the return address you can't step over. The problem is that there is no return statement on the 9900, so it first makes sure the instruction in question set a return address (otherwise it just steps), then it runs until it hits that address. Also, if you breakpoint inside the step-over routine, the step over is cancelled. Finally, of course, make sure Scroll Lock is on. When Scroll Lock is off, breakpoints don't work (but neither do the shortcut debugger keys). it's possible you are hitting a bad state and it's losing track of what it's doing, I haven't logged enough time with the new step-over code myself, but I just tried it again here on BL's and it did the right thing. If you can give me a reproducable failure then I can fix it.

The REF/DEF table is possible, I guess, but now you're asking me to interpret the operating system. I'd kind of like to focus on the hardware till that's closer to my satisfaction. I will keep it in mind, though, because I have parsed that table manually as well. A list of branches is definately a long-term sort of idea. That WOULD be a tricky thing, since you'd have to pre-emptively execute the program and take every branch to find them all. I see your problem... my first thinking is that you will save yourself a lot of hassle if you have your assembler output a listing file, and use that as a reference. Absolute code is a bit easier to debug for the reasons you list, but if you absolutely (hehe) must develop with dynamic code (many reasons why you might!), you can still help yourself out. Do something early in your program that you can breakpoint on, like a write access to a particular address in console ROM, or loading a particular value into a VDP register. Remember that the debugger is not limited to PC breakpoints, they are very flexible and there are all kinds of ways you could trigger it. (This is partly why I've resisted "breakpoint" psuedo-ops in the emulation). Even the ROM example you list is pretty easy.. the structure of your ROM header will rarely change, so if you know that the START label in your header will always be at, say, >600A, you can breakpoint on read to >600A as the console won't look at the start address till you select the cartridge in the menu (IIRC). Agreed this is a bit of a hassle, but I've used the external listing file to solve that. Again, take another look at the breakpoints. It's so easy to catch a unique behaviour in the code, and if there isn't already one, you can easily add one. For example, if you added a MOV R0,@>0000, then you can add a breakpoint on write to >0000. It'll have no effect on the console or the emulation, but it's easy to trap. And you could set up a whole set of these breakpoint "IDs" with different target addresses, and with a single breakpoint trap all of them (using a range), or specify only the ones you want. Most of my personal work is with absolute code, so I just look at the listing file to get the addresses I want. I'd like to have it parse the listing file or object file someday to get labels... the listing file is more likely since the object file will only contain DEFs. Sure it is, the emulator does it all the time. The caveat is that the first instruction you start with needs to be valid, if you start on data you may get misaligned instructions. The inability to page is more of a design issue right now, there's no serious reason it couldn't be done, I think.

Okay, yeah.. it's very likely the file type - this is not a bug in Classic99, more of an incompatibility. The same thing would happen on real hardware if my virtual disk device existed in real life. This is still theory, I haven't confirmed it, but what happens is this. Extended BASIC, like TI BASIC, can run programs from VDP RAM. When a program fits in VDP RAM, XB saves it as a PROGRAM type file, so that it can be directly loaded into VRAM. However, when a program is larger than available VDP RAM, XB saves it as an Internal/Fixed/254 (IIRC, might be DF...) set of records, so that the loader can do it in pieces. The problem comes along when you introduce the Disk system -- the TI Disk Controller reserves some memory at the top of VDP RAM, making the available size of VDP smaller. For example, it's possible in XB (and TI BASIC) to have programs that load on cassette (which doesn't use these buffers) but not on disk. Usually a CALL FILES(1) would free up enough memory. Corcomp and Myarc copied TI's disk system, so do the same thing. Classic99 doesn't use VDP buffers at all for its disk system, meaning the same RAM is available as on the raw cassette system. This is not normally a problem, but if you save a file from XB that is right near the edge, it may save as a PROGRAM image rather than an IF254. In that case, the system that loads it needs to have enough free VDP RAM to bring it in as a single chunk. Technically, IMO, this should be an advantage, but I've lamented everyone copying the floppy controller so many times before. There are probably some CALL LOADs you could do to fix it, we'd have to find the pointers that set the top of VDP RAM... unfortunately CALL FILES() does nothing in the current release, so you can't use that to fake it. My ultimate solution was to add support for the real disk controller, but I haven't done that yet. If it's going to cause people problems, though, I could implement the buffer space updates just to make it easier to transfer to a real machine (since that was always an important goal of the emulator). You may be able to verify this with TI99DIR - just check the file type of the version saved by Classic99 against the version saved in Win994A and see if it's PROGRAM versus (something else ).

Wow! It's great to see a different approach to the cartridge problem, I think you did some thinking outside the box and it was very cool to read about!

This thread kind of kept running at top speed after asking me to look at something, so my question is perhaps a bit late, but I don't follow what you think is wrong with Classic99. I can tell you that Classic99 has more free VDP RAM in BASIC and XB than a real system with a floppy drive, and perhaps most emulators, because it doesn't use a TI, Corcomp, or Myarc disk controller system. So if your file is right at the threshold, it may be using a PROGRAM image that is too large to load on such a system. That's my best guess based on what I'm reading here. But I'm not really sure if it's resolved or still stuck, which files I should be looking at, and what the incompatibility is against.

Great I had looked for 1.010 version of win994a but it doesn't exist. This fixes the JH problem right? I don't know the version number offhand, but yes, it fixes JH.

I don't think we had a thread for this, so I figured I'd start one, since many people here are using my emulator. 11 June 2010 -Add ability to breakpoint on uninitialized memory read (console RAM only for now, no AMS) -added 3x scaling to the video size menu -save default scaling size -Fixed broken continue and Step Over in debugger -Added cycle counting and hex data to disassembly window -changed default memory pointers to something more useful than R0 -made changing the filter mode reset the screen scaling size -debugger now allows changing any memory type from any view window - VDP now has a V prefix, GROM has a G prefix. See docs. -added memory type enums to the debugger display (code change only) http://harmlesslion.com/software/classic99

Looks nice, John!

I did miss one point I should have addressed, until Cory releases an update to Win994A, you can get his patched binary from me at http://harmlesslion.com/temp/WinAsm99.zip Just backup the old EXE and replace it with this one. Cory provided that binary to me directly as a test, so I doubt there's any warranty. Also Classic99 supports up to 128k of bank-switched ROM with Jon's scheme.

Error 2 (is it 02?) looks like it means bad attribute, which might mean the file type is wrong. My PEB isn't hooked up, can someone else try?

Here's a version that fixes the field 2 issue. It was a frustrating one. I was able to prove that my RNG produced more or less random numbers, but the relationship between 2-3 numbers in series, especially at any particular bit position, was too frequently predictable. So the next effect was that almost every time it chose a bad effect, followed by the zombie effect, the next random number (field) had the same value in the lower 2 bits, which resulted in field 2. I tried a few ideas to drop unpredictable delays in there, but finally just gave up and detached the field selection from the RNG, using a free-running counter instead (seeded at the same time as the RNG is). That seems to work. I had to do some optimization, so I found a free register, and loaded it with >0001. Then, everywhere I did a LI Rx,>0001, I could replace it with MOV R8,Rx, saving two bytes. With that I freed up a comparably large amount of ROM space, and added a feature I felt was badly missing - a brief explanatory delay when you drive off the zombies. Even with that, there are about 72 bytes free in the ROM now. If someone else would like to hack away on some of Kurt's ideas, I surely have no objection! But for now, here's the new version that fixes field selection, at least. ZombMotif.zip

The way it works is like this... An EPROM is a standard ROM chip that you probably already understand, but I'll go into detail so the differences are more clear. An EPROM has a set of input pins called the address bus, and a set of output pins called the data bus (ignoring the programming phase - my description only covers reading it in the cartridge port.) The address bus size depends on the size of the EPROM, but at the cartridge port it has a range of 8k. The data bus at the cartridge port is always 8 bits wide. When the TI wants a byte of data from the EPROM, you simply do an assembly instruction that reads memory, for example, MOV @>6000,R0 will move the first 2 bytes from a cartridge EPROM into register 0. At the hardware level, the console first determines where >6000 is. Discovering it is at the cartridge port, it strips off the high bits, sends the address >0000 to the cartridge port, and triggers the cartridge selection pin. The EPROM sees the select, sees the address >0000, and puts the first byte on the data bus. The console reads the data from the data bus, then repeats the process with >6001. Once the console has both bytes, it copies the result into R0 and the program continues. Note that ROMs and EPROMs work the same way from this point of view, the only difference is one is externally programmable (which I won't go into detail on). EPROMs are used in thousands of machines and EPROM programmers are very common and easy to come by (and they come in almost every configuration you can dream of, but 8-bit wide EPROMs are most useful to us on the TI). GROMs work very differently. GROMs have just a single data bus, and two control pins. The data bus is 8 bits wide, just like in the EPROMs. One control pin specifies whether you are dealing with DATA or ADDRESS, and the other controls whether you are READING or WRITING. Although any combination is possible, GROMs will ignore the combination WRITING DATA, everything else is valid. TI GROMs (I won't discuss clones, GRAM devices, or other such) contain 6k of data each. In order to manage 6k of data through a single 8-bit port, they have their own internal address counter, which you set by using the WRITING ADDRESS combination. Once it is set, every READING DATA operation automatically adds one to the internal address, so that you can just keep reading without having to set it every time. This makes accessing the GROMs more work, because you have two limitations. First, you have to explicitly tell the chip what address you want, and second, the automatic system in the console for turning bytes into words of two bytes won't work on them. Without going into too much detail, the GROMs are accessed as if they were devices, like the video chip, by reading and writing to special reserved addresses on the REAL address bus. So to duplicate the case of getting two bytes from >6000 in the GROM space, the code looks more like this: LI R1,>6000 * copy the address we want into a register SWPB R1 * send the lowest address byte first MOVB R1,@GRMWA * write the first byte to write address - this sets the WRITING ADDRESS pins on the GROM SWPB R1 * get the other byte ready MOVB R1,@GRMWA * write the second byte to write address - now the address is loaded in the GROM chip MOVB @GRMRD,R0 * get the first byte of data, this address sets the READING DATA pins on the GROM SWPB R0 * prepare the register MOVB @GRMRD,R0 * get the second byte of data from the GROM SWPB R0 * put them back in the right order Not only is it that much more complicated, but GROMs are also much slower than EPROMs, because of all the address work they do internally. While EPROMs are fast enough to respond to the console in normal memory times (easily!), GROMs actually have to halt the CPU while they work, and a single access can take 3-4 times longer than an EPROM access. (A GROM made with modern electronics would easily be fast enough, but the console GROMs will still enforce the slow access as they can't be disabled). GROMs work similarly to modern "serial EEPROM" devices, but the problem is that they are 8-bits wide and use a different control mechanism, so there's really no modern equivalent we can drop in. In addition, EPROMs are faster to respond, easier to work with, allow faster code, and can run assembly language (GROMs can not because of the way they work, at best they can run interpreted GPL). The GROM sole advantage was that they allowed 40k of data at the cartridge port, while EPROMs were limited to 8k, but with simple bank switching hardware like Jon's design it is trivial to expand EPROMs far beyond 40k, removing even that advantage. The only reason my converter outputs GROM instead of ROM images, was because I wanted to give people a simple way to distribute their games for emulation, and the larger size of GROM was idea (especially since no emulators supported a standard EPROM bank switch scheme). But I will change that when I get some time! Also, the only reason I'm working on a real GROM simulator is I want to use the GROM port to access SD devices for gigabytes of data, without conflicting with the ROM port, and also to provide a way to reproduce older, useful carts like Editor/Assembler, should we ever need to.

The same farmhand is deliberate - since the farmhands appear by number, and are not individually tracked, only the last farmhand is ever sent out to battle (for instance, when you HAVE L'il Rex, I can't send out Katie Sue because if she bites it, it's L'il Rex who will disappear ). The field 2 bug I thought I saw, too, but I thought I corrected it. That is annoying, so let me take another look at it. Remember this is a mash-up of two unrelated games. I did not strive to modify the existing games. Hm. That's odd. That sounds like a crash, because there's no place in my code where the return key is tested for. I played numerous games through to 2000, when it ends. Corerct. This is the way the original game functioned. You have tons of great ideas, Kurt, I have to say I liked all of them. But again, I didn't intend to change the original games. Also, with only 4 bytes of ROM left, there isn't any space for the code for any of those concepts, without tons more optimizing work. I really meant this as more of a curiousity. With a double bank 16k cart there would be tons of room for improvements, including animation of the Zombies like I wanted, bullets instead of lasers, actual crop/field damage based on the zombie minigame, different sprites for the different farm hands, an intro cut scene, and I think all of your ideas would be great too, but I can't give it that kind of time. I am pretty backlogged on other things I've promised to do, and they need attention more than this.

You guys have advanced a bit beyond the bit I wanted to touch on, so let me drag you backwards half a step just to explain my tool. My cartridge creation tool creates GROM images for emulation out of EA#5 programs -- but all the GROM code does is copy the program back to RAM and start it. So it's essentially just a loader. I have a version in progress that will do the same for ROM images that will work with Jon's bank-switching EPROM carts, but that has fallen so far down my backlogged task list that it will be a few months before I can get to finishing it. My single-chip GROM solution works now, but I need to get back into it, too, as right now the only way to program the GROM code is when you program the Atmel itself (I want to make it programmable by the TI). This is higher on my list but still backlogged... couple months away. Back to the discussion on moving your program to ROM!