Tursi

If we make a box, I want that as the "reviewer's quote" on it. hehe. Thanks! It was fun.

GROMs are sadly not compatible with EPROMs. There's no /easy/ way to make them yet. I have my GROM simulator working - it runs on an Atmel microcontroller and gives you a single-chip GROM replacement, though the pinout unfortunately could not be made compatible. But it's not quite ready to release, I need to add a little more code to allow larger versions of the Atmel to support multiple GROM bases.

Just time for me. I have two things I need to work on but they are just being pushed aside by general life issues.

Okay, declaring this one done, barring any massive bugs. I've even tested it on real hardware! The end screen is as simple as I threatened, but I also fixed a few more bugs. There are 4 bytes free in the ROM (but interestingly, almost 40 bytes free in scratchpad! I ran out of ROM long before I ran out of RAM - I moved a lot of the TI Farmer arrays to ROM and saved both RAM and ROM space). I'm sure it could still be optimized, I was still able to chop sections up and rewrite them for tighter space, but it's there and it works and good lord, I'm done with it. Also up on my webpage at http://harmlesslion.com/software/zombie (this archive has the correct source in it ) ZombMotif.zip

If anyone would like to see more 99/4 inside photos, I made a gallery on my website containing detail shots from my own machine when I dismantled it. Seems like every 99/4 is slightly different though! They are full resolution photos so you can see the details (although I watermarked the external shots to prevent people from using them on EBay ). I figured there was not enough on the web about this machine! http://harmlesslion.com/gtwo/v/Projects/ti994/

All right.. I spent far too long on this, and did way too much. But.. everything is end except a better ending screen. Not sure what to do there yet, and I only have 12 bytes left in the ROM, but I'm sure I can scrape up enough space to draw the farmer again with the final score. I'm trying to keep all three games in the ROM, it's so close to working now that it would be a shame to take out the other two options. In addition, this version fixes some serious random number bugs, and the ZomBXB white screen issue. ZomBXB is also playable by keyboard as well now. It also implements MOTIF mode a lot more fully (as I said, I think all that's left is the end-game screen), and includes a readme based on Codex's original document that explains the new changes. Zombie attacks still come randomly, but they have a different effect -- if you fail to drive them off, which basically means blasting enough of them -- they will 'foul' the land which prevents parts of it from being farmed or even plowed. If you lose a farmhand to the zombies, only one quadrant is fouled, but if Zombie McOwen falls, the entire field is fouled. I went way overboard on this and could have made my life easier, but it's so close now that I don't mind. However it's also 6am and I need to sleep! ZombMotif.zip

TI joysticks are digital, on/off only, but in the original concept, they were going to have up to 3 bits of resolution in each direction, with the return values going from 0-7. The 99/4 ROMs contain some code for this, and is the only official reference of this design (I believe MESS implemented emulation of it, even though no real such joystick hardware has been found?). The real values are 0 or 4, if I had to hazard a guess I'd say that's MEDIUM.

Yes, it can overrun if you set the address then immediately read the data port, but running with no wait states (doesn't matter if it's scratchpad or a modified console). It won't happen every time, since you're only about 2uS too fast (out of 10, so 1 in five such accesses could be expected to fail). It will not overrun if you set the address, delay, then read as much data as you like. It's the delay between setting the address and reading the data that is easy to make too short. It should not overrun on writes thanks to the wait states combined with the read-before-write. The stuff we saw with the logic analyzer exactly matches what we saw in the datasheet and the known TI-99 architecture, there were no surprises there. It just took us a few tries to include all the different parts. Working at 3.58MHz works fine by the numbers, too. That's 20% faster on the CPU, with a cycle time of 0.28uS instead of 0.33uS. So 10uS is 35.8 CPU cycles on the 3.58MHz machine, and 30 CPU cycles on the 3.0MHz machine. 5 cycles difference is less than 1 instruction, you'll probably be good most of the time.

Scratchpad and RAM with no wait states run at the same speed, there's no need to retest that (unless you really want to). The mod just adds the normal 32k RAM areas to the circuit that disables the wait state generator. The 3.58MHz tweak is interesting - are you saying it does not have any problems running at 3.58MHz with the wait states disabled (ie: running full speed)?

It means you're a programmer who doesn't use defines, constants OR comments in his code. Usually you'd put the pointer in a define or pointer variable so could could use "*VDPRD" or just "VDPRD", depending on how you defined it. #define VDPRD *((volatile unsigned char*)0x8800) ... int x = VDPRD; or volatile unsigned char *VDPRD = 0x8800; ... x = *VDPRD; The nice thing is that if someone else does the headers for you, you don't have to worry about the definitions. Anyway, looking forward to trying this, but unfortunately (for me) it will probably be a few weeks. Don't drop it!

I thought you guys (Marc and Matthew) were both there on whichever list it was where we hammered this into the ground, getting the /actual/ timing from the console during VDP access (ie: there's no need to "rely on information from Thierry's website"). When we left it, all that was left was verifying the theories, which none of us did. ). Unless you guys don't trust my results, I know I get chewed out every few months from someone for "pretending" to know what I'm talking about. No, it doesn't, so it should be the same as Marc's test. So, assuming registers are also in 0-wait-state RAM: CLR R1 10 cycles MOVB @R0LB,@VDPWA 14 + 8 symbolic + 8 symbolic + 4 read vdp + 4 write vdp MOVB R0,@VDPWA 14 + 8 symbolic + 4 read vdp + 4 write vdp MOVB @VDPRD,R1 14 + 8 symbolic + 4 read vdp SLA R1,1 12 + 2 ORI R0,>4000 14 MOVB @R0LB,@VDPWA 14 + 8 + 8 + 4 + 4 MOVB R0,@VDWPA 14 + 8 + 4 + 4 MOVB R1,@VDPWD 14 + 8 + 4 + 4 The 4 clocks are the wait states imposed, and every write has a read-before-write cycle. A cycle is 0.333uS. According to the datasheet, the VDP needs 2uS after setting an address before it is ready to make the data transfer. It then takes anywhere from 2-8uS for the transfer to actually occur. Bitmap mode is the worst case, so the full 8uS is more likely to occur than in other modes - that's a total of 10uS, which takes 30 CPU cycles. This information is all out of the respective datasheets. Note that the 2uS delay after setting the address doesn't apply to subsequent reads or writes wrt the VDP, only the 2-8uS window applies to those. Most likely, it's the read that is failing. But it's not going to be 100% reliable about failing, which makes this sample code a little tough. Sometimes it will work. It depends exactly when the CPU request happens compared to what the VDP is currently doing on the screen. Anyway, the reason it's likely the read, is it's the shortest time between writing the address and accessing the data register. Since the address write is the last thing the previous MOVB does, and the data read is the first thing that the next MOVB does, you've only got about 20 cycles or so between the write of the address and the read. Even so, I did prove in that thread that READS could outstrip the VDP, only writes appeared to be safe (and based on this information, maybe not after setting the address). To quote: But this was talking about sequential accesses -- you need a little extra time after setting the address. The write might just be safe, as the actual write will occur right around the 30 clock mark, but the read is definately too early to be reliable. (Also note the above treated the fastest instruction as a MOVB R0,*R1, where R1 contains the VDP address, or vice versa, anyway, using register indirect to access the VDP and Register for the data. We talked about other hacks like LIMI later.) Of course, with the program in wait-state RAM, you gain 4 extra clock cycles for every word of program, which pushes your read up to 30 cycles between the address set and the read.

As a game programmer, can I note that having up/down events to deal with really sucks? 99 times out of 100, you just want to know, "Is the key down NOW?" Event messages force you to track that state yourself, which is kind of a pain. Since the TI keyboard is scanned by the CPU, that means your library will need to track the current state in order to report up/down events, which in games will usually be translated back to a current state. Of course, you could just have a "get state" function as well, but I question the value of the events plan? The reason modern OSs work on events instead of current state has less to do with usability and more to do with hardware -- the PS/2 keyboard works in just that way, by sending up and down events, and even repeat information. Interestingly, USB keyboards go back to giving a "current" report (which is translated today into the old system by software). Just my two bits, if you're intending that as a game library.

Very interesting! I will have to dig into this when I can, too! I took at stab at it some years ago but did not get to a working state. I'd love to be able to delete my files and say there's a good one now!

We need to see the code to answer that question. Bitmap mode is the most memory intensive VDP mode, so it is of course the worst case scenario. But with a posting of the code we can run through the cycle counting and see if it makes sense, or this is new information.

On what controller? The TI device system is controller agnostic, but the largest fields are 16-bit. So far as the PAB is concerned, you can access up to 65536 records of 255 bytes each, for a total of just under 16MB. The TI Floppy Disk Controller direct sector access supports up to 65536 sectors. That's also 16MB. The TI Floppy Disk layout supports 16-bits of sectors on the disk, but for a single file, the limits are imposed by the cluster list. Only 12 bits are available for the starting sector of a cluster, reducing the practical maximum size of a disk to 1MB (as files can't be stored beyond that sector on the disk), and the cluster also indicates the full size of the file in sectors (not the number of sectors in this cluster), so again the file is limited to 1MB. Classic99 doesn't use the TI Floppy disk controller and is not limited by it's settings, including the cluster map. However, it is limited by the information available in the PAB. I haven't tested it, but I'd expect number 65535 to be the last accessible record. I can only speak if it's Classic99 you are using. It's not DOS anyway, first off, you aren't running DOS. (I know, that's nitpicky ). Unless you are running FAT12, your smallest maximum filesize under Windows is 2GB. If you wonder if Classic99 is truncating your file, what does the debug log say? No, there's no SLL because it isn't needed... SLA is so named because if the sign bit changes, it sets the Overflow bit, but if you aren't looking at that, then you won't see any difference. From the E/A manual: The SLA shouldn't be honoring the sign bit in any other way. It doesn't in Classic99 anyway. But it does sound like a sign bug in there somewhere. Classic99 uses 32-bit values to manage files, so it shouldn't be there (but it's possible). However, if it happened I'd expect an error in the log.

I dunno, I think it would influence the decision some. If they thought tweaking up the emulator would be less work than the entire OS, not to mention they could test it on another, existing machine, it might seem like the path to take. If you don't know your final hardware, but you have to build the OS code anyway, what do you do? (Remember, it's not just BASIC, the entire boot system for the console is written in GPL, right down to hardware initialization). The proposed CPU for the TI was based on the 9900 series but it was not the 9900 - all likelihood is that final specs were not available, especially since the prototype silicon didn't work. It's very likely that by the time Microsoft started the task, they already knew the CPU was in trouble and might not be the final one. Microsoft at the time had a history of writing emulators, then writing their code in those emulators. So creating an emulator for a CPU very close to what they thought the CPU would be, wouldn't be out of line. One problem I have with my theories is I don't know who wrote GPL. As for the GPL CPU, I've heard that rumor too.. but in looking at GPL, it would be an insanely complex piece of silicon. I have my doubts whether it could have been done at production costs back then. I suspect the dropped 8-bit CPU is the one that started that rumor.

New version here.. I decided to leave all variants of the game in the cart. This is just the barest foundation slapping the two games together. You start in TI Farmer mode - Zombies attack when they normally would (or if you already have 5 farmhands it is slightly more likely), even so you can go a full game (400 turns!) without seeing them. There's no transition screens or introductions or anything, it just blips back and forth. But it's progress and sets the stage for the final stuff I want to put in there. In the ZomBXB part of the game, the only way to exit currently is to die, and this has no effect on the rest of the game yet. I've also renamed the image to MOTIF, and this fixes a bug in TI Farmer that would blank the whole screen. ZomBXB still has the bug where the screen goes white sometimes. TIFARMER.zip

As I recall, the answer to that is yes. I have a couple of floppies with single "large" GIFs on them.

I'd be happy to share my code for writing the TIFILES headers on the fronts of the files, too, if you'd like people to be able to use the files on a TI rather than RAW. (Actually.. it's pretty simple, since the TI Artist files are always 6144 byte PROGRAM image, the header is always the same 128 bytes, I guess you could just copy off one of mine ). I will have to give this a try.. being able to edit the post-conversion images will be very useful!

Bingo!! That one bites me all the bloody time! hehe. SOC is OR. SZC, well, I finally have started to live with it. um... I really should have a good list here, but I don't. My worst ones: 1) When comparing for magnitude (ie: greater than, less than, etc), remembering which way to order the arguments and remembering which jumps are for signed or unsigned, and which combinations also have 'or equal to' available... (JH, JHE, JL, JLT, JGT... oi...) 2) CRU was said. But I dislike everything about it enough for it to be worth repeating. 3) MPY and DIV were touched on, but while I remember WHICH registers to use, I sometimes forget that one of the arguments to each is 32 bit... 4) I have trouble remembering the names of the shift instructions. This is not 9900 specific -- in fact if it were just the 9900 I'd be fine. But there's no consistency across assemblers for what order to put the words in. They all have an arithmetic shift left... or is it an arithmetic left shift, or a shift left arithmetic.... which mneumonic will compile today?

I've spent a fair bit of time in the GPL interpreter recently as part of some debugging I was doing... it's surprisingly inefficient. For instance, it fetches the data from target addresses, whether it needs to or not. I suspect if we actually sat down with the stuff we know today, we could make GPL snappy enough to resolve a lot of those BASIC woes. (I don't intend to, but it looks feasible ). That said, I definately believe it hurt the machine. TI BASIC was all you could do with the unexpanded console, and as its performance was miserable, the entire machine gained a reputation for being very slow, when in truth it kept pace with and outclassed many of its competitors (I remember my Apple 2 friend being so jealous of how fast the TI could load a bitmap image - and that's with us loading 12k and the Apple only loading 6.5k! Not to mention his jealousy of sprites...) Anyway. I haven't seen anything authoritative, but GPL really looks like it was a stopgap to allow development of the system software before the CPU was ready. The loss of the originally planned 8 bit CPU is well documented, it's possible that GPL was forced into larger service than was intended due to the delays... (theory, not fact!) Of course, since the CPU couldn't run from GROM, it's also probable that GPL was a big part of TI's marketing decision to control their market.

It's not finished yet. Just need to merge the two now. You'll find most of this code is pretty primitive -- in order to reduce the number of new bugs I introduced, most of the time I opted to port the Extended BASIC code instruction by instruction, without much concern for the overall intention. Only in a few places, and mostly to save RAM, or if it was more trouble than it was worth to do exactly in asm, did I restructure the code.

You will probably find you have quite a ways to go before you run out of performance --- and then we're all here to help you optimize.

Here's the working version of the cart with both TI Farmer and ZomBXB working.. gameplay on both is comparable to the Extended BASIC versions (but much faster), so this version of the cart is probably worth holding onto just for that. There may be a bug still in ZomBXB.. I occasionally had the screen go white on me, but I didn't capture the bug when it happened and couldn't reproduce when I went back to it. If anyone notices it happen in Classic99, let me know what direction you were going (if you know), and if you can open the debugger before you get killed, let me know the value of VDP Register 7 (then I can set a breakpoint for that value myself ). TIFARMERASM.zip (obsolete, look further down) Source included, of course.

D'oh... hopefully you'll be able to grab it. Else I can throw it on my server for you. Yes, coding it to run from cart. Okay so far, I have 24 bytes of scratchpad RAM left and 2k of ROM or so... so it should fit in a standard 8k ROM. I got ZomBXB ported last night so today is the (much longer) debugging phase. I also updated TI Farmer to remove the string variables (like MS$) and have them point direct to ROM instead, that saved a lot of much-needed scratchpad. ZomBXB has a few additional challenges since my code doesn't support the console interrupt routine - the title screen is static (that's okay since it will go away when I combine the two), and also I need a way to emulate the time countdown for CALL SOUND (but I have a plan for that). ZomBXB also had no delay code at all, and desperately needs it (the title screen vanishes instantly, and you are usually dead pretty much instantly when it doesn't crash ). With a little luck and dedication, I can post that version tonight.