FarmerPotato

Back on topic: This code works on my 4A, but it assumes a GROM address for the char defs. Is there a better way to look up the char defs? Are there different GROMs out there? * copy 7 byte grom char defs to vdp. * assume 06b4 is the char table (seen in classic99 4A grom) * they are 7 bytes per char so add a 0 after each 7 bytes * R0 VDP address * ---- * R1 scratch * R2 scratch chara: ori r0,>4000 swpb r0 movb r0,@VDPWA swpb r0 movb r0,@VDPWA li r1,>06b4 movb r1,@GRMWA swpb r1 movb r1,@GRMWA li r1,>5f ; number of char defs chara1: movb r1,@VDPWD ; insert a zero byte li r2,7 ; bytes per char def chara2: movb @GRMRD,@VDPWD dec r2 jne chara2 dec r1 jne chara1 rt

Very nice!

Would you like to modify your console? It's beginner level soldering. Read about fixing the alpha lock problem once and for all by adding a diode (follow link on that thread to MainByte article).

Like F18 with a hole melted for the VGA port? Also the alpha-lock joystick mod.

Hi all, Please take general discussion of using keys to TI-99/4A Computers : Game controls: keyboard ESDX, WASD, joysticks Talk about assembly programming and KSCAN here.

Discussion of love/hate for ESDX keys, joysticks, other key layouts like WASD There were posts about key preferences in the "Assembly on the 99/4A" thread, following a discussing of KSCAN. I am quoting them here, hoping to divert the talk to its own thread.

Please allow the user to choose a keyboard layout? I suppose by two hands you mean left hand on E+S, right hand on X+D. I have seen people adopt this. It strikes me as odd when three fingertips is enough for me. I have always used my right hand thumb on X, middle finger on E, index finger on S+D. My index finger can move most quickly of all to switch between S and D. I am not a big fan of WASD. If I use the middle finger for both W and S, that muscle is slower to finish the movement (tendon causes three joints to contract) than the other movement in ESDX .WASD feels uncomfortable because my middle finger is above average length. That said, we all have idiosyncratic wiring between brains and fingertips. Also, hjkl.

I thought of that, too.. I took that feature out of the Geneve GPL version (unpublished, whereabouts of floppy disk unknown)

In Bubble Plane (1988) I added a CRU bit test and a message saying "RELEASE ALPHA LOCK TO BEGIN PLAY". Despite what I just said, keyboard and joystick gameplay and menus (including joystick high score initials entry) were both supported.

I understand you're talking about the menus, not gameplay. But for gameplay, I don't like joysticks. I have more dexterity in my fingertips on the keyboard. I resent that the Atarisoft games generally don't have keyboard controls. Late games like Barrage and SpotShot let you push Fire instead of Redo. You only needed the keyboard for Back.

OK, KSCAN will be toast. I will check for movement keys/fire, maybe Redo/Back. The column setup can be combined. Thanks Rasmus! KEY_FN EQU >000E KEY_FS EQU >0106 KEY_9 EQU >010C KEY_S EQU >0110 KEY_X EQU >0114 KEY_D EQU >0210 KEY_8 EQU >020C KEY_E EQU >0212 KEY_Q EQU >0512 JOY_FI EQU >0606 JOY_LT EQU >0608 JOY_RT EQU >060A JOY_DN EQU >060C JOY_UP EQU >060E

Right.. KSCAN. I'm not using PAD aggressively, just my WS in >8300. I must re-read this discussion if I want to take over more of PAD (like, storing my VDP write loop code). The music player is based on FORTI in pure assembly (not FORTH this time). I'll be posting all the source here shortly.

I am using your vsync loop with success. My game loop is: LOOP LIMI 0 wait for vsync draw 500 bytes to VDP for scrolling bitmap playing field and sprites increment counters test counters to see if sprites should go to next animation update playing field in CPU RAM tell music players to go 1 tick KSCAN The music is playing at regular speed and my tick counter is advancing at 60 Hz so all's well. I'm not giving the ISR any time.

The purple ceramic chips with windows are common EPROMs. The 2532s are the largest there, and still have practical replacement use in TI-99/4A peripherals. The board with the white chip: probably some kind of industrial controller. The white chip with gold pins looks like a TMS9900 cpu: http://www.wikiwand.com/en/Texas_Instruments_TMS9900 I don't think the board is from a computer series (like TM990) because it has no card edge, but I could be wrong. Most of the CPU lines seem to be buffered to the 50-pin connector at the right edge. Probably this connected to another board, hopefully one with memory on it, because I don't see any RAM or EPROM here. The 50-pin connector on the left edge goes through a lot of line drivers and buffers, so it is probably an interface to external signals. Thanks for sharing these photos.

I looked for IO Error 43 in the TI disk DSR source code. I did not find it yet. It means Illegal Operation on Seek/Rewind/Restore. Some guesses: 1. I wonder what is the expected error when you enable Protect Disk (the anti-copy protection flag, letter P on sector 0) 2. There was an error trying to move the head to a particular track (but this should be a 6 not a 3) Maybe it is a power supply issue. Try a different Pbox? Drives draw the most power when spinning and seeking.

I've got 2 ideas going: one is re-writing a 16x16 area in the bitmap name tables to cycle through 8 versions of the characters, to make it scroll one pixel at a time. This is 16 writes of 16 bytes each to the name table. the other is rewriting the corresponding pattern table (hopefully leaving color alone) which is 2k of data. I've organized the name table so that it increments characters going down, not across. That way I can blast 64 bytes for a precomputed column of 8x1, then do the next, without setting up the address again. Doing the second, it takes more time than one refresh to write 2k, so yes it's tearing obviously. It's going at about 4 frames per second.

I think I am seeing some tearing. And I am enjoying unrolling loops to just blast it all out! Hmm, I forgot that I could move the name table from >1800 to >3800 to do page flipping. But isn't there something with reading VDPSTA? I did something with the 9938 back in the day to synchronize page flipping (register write) with vertical retrace, because it was tearing even more obviously during a page flip.

What is the technique to synchronize screen updates with the vertical sync? To avoid tearing by trying to draw in between video frames. My game loop is like this: LOOP enable interrupts briefly write screen and sprites to VDP KSCAN update internals B @LOOP I'm not sure the VDP writes still take more than 1/60th of a second, but I'm working on that. 3 address changes for 3 blocks of 128 consecutive bytes seems like it could fit into one refresh cycle. 2 writes to Bitmap name table and another to sprite attribute table.

It was gone when I looked just 30 minutes after. I would have snapped it up to substitute for a dented 99/4 (my second best one). I paid $250 for one in good newish condition many years ago.

You're welcome!

I started working in Magellan for bitmap mode. Version 3.3 x64 made the Export Assembly dialog work for me. I could not get the dialog in 3.05, 3.1, etc. The link on the Development Resources thread points back to the 3.05 version. This is the most fun I've had in a great while. Tak for dit forbedring! -Erik

Here is some code that implements the EA5 loader. You might want it if you use EA5 format for run-time loadable segments, or launch different programs from a menu. This code shows how to load one, called 'DSK1.K2P'. loader.txt is the simpler code. loadea5.a99 has some debugging code in it to display progress and such. loader.txt loadea5.a99