Dexter

Of course that worked out fine! Now I have the values as they should be. Finally I have sort of a playable version! After starting the game “S”, respond with the keys 1, 2, 3 or 4. A wrong key press responds with altering 2 and 3 continuously. Waiting longer than 5 seconds, responds with the sequence 4, 3, 2, 1. The game auto starts with the XB Cartridge. Of course it comes with a free bug. runme.dsk simon.a99 tiplayer.a99 simon3.vgm.a99

Great video! Yet another Like !

Very nice idea for a thread! I had an idea for a PEB replacement. I'm thinking of a Printed Circuit Board where cards for the PEB would fit in. The board would have an ATX main board form factor, that way it would fit in any computer case. The card could be plugged in as if they were PC cards. The power supply could be any PC power supply. This idea is nagging me for quite a while.

I have followed the development of that C64 Reloaded board up close, the developer has rejected a LOT of requests for “improving” the new C64 board. The result is an “authentic” and stable functioning Commodore 64 board, recreated from the best revision of the available C64 main boards. All IC’s that makes it a Commodore 64 are NOS or pulls from the past, so the compatibility is 99.99% guaranteed. The PCB, glue logic IC (that connects the main IC’s together) and the power supply are new and come with warranty. You have to buy at least one functioning C64 of a specific type, to make use of the new board, that makes the price about €200,-. IMHO, the quality of the TI-99/4A main board is much higher than that of the Commodore 64. Making a new board would rise unnecessary costs, which would be better invested in a new PEB replacement.

A decent machine language monitor and CPU RAM, to be able to program and use ml on the bare console.

By each day I get more respect of what Rasmus_M, ehm li r1,Rasmus SLC r1 Asmusr-M pulls out of his hat. Progress is going slow on my SIMON game, while Asmusr-M keeps on presenting new things as if it were nothing! AWESOME!

I hope that I keep remembering now, everything works out OK when working with words. I have to get used to the byte commands. This part of the problem is solved now. Of course, you’re right. After correcting that, it almost works out fine. Thanks to both of you! The graphics are converted with Magellan, a fantastic tool, but on some bytes it pick background color and pixel color reversed. Mostly I have two colors in one character. While importing, Magellan doesn’t know which color of the two is background or pixels, so it probably picks them randomly. To get that right, I have to correct each “reversed” character by hand. Or is there an easier way?

Well, I’m using half bitmap mode, and the used bytes for the color table are not sequentially as in normal bitmap mode, but scattered over the place. So for the digit 1, there are a few specific characters used, which have do get another value in the color table. S123G MOV R11,*R10+ * Push return address onto the stack li r3,0 * r1 is index ld1 movb @dig1(r3),r4 * load value from dig1+index ci r4,0 * end of table? jeq nld1 * yes, exit loop li r0,>2000 * start of color table a r4,r0 * r0 holds now the actual color table location li r1,>e1 * grey pixels on black background bl @vsbw * store the byte in VRAM inc r3 * increase index b @ld1 * next character nld1 DECT R10 * Pop return address off the stack MOV *R10,R11 B *R11 dig1 byte 145,146,160,171,172,183,209,210,0 I’m using the Indexed Memory Addressing mode, to write >e1 (grey pixels on black background), to the specific color table bytes. The screen gets pretty messed up, so I’m obviously doing something wrong.

That's the second time I read about the improved BASICLOAD, first with the XB2.7, and now here. I probably have missed something, but what does it do, and which program is it?

It was sort of a mix actually, on one hand trying out some arbitrary functions of the F18A and unlocking them, and on the other hand changing the palette with a few values. But indeed, it’s a little bit silly to make the game dependent of the F18A, just for the altering of the palette. I’ll most likely scratch that from SIMON, so that it’s also playable on 4A’s without the F18A.

Very cool as always! I just kept looking to a few more of your other videos...

Good point, that’s very often the case. However, I’m using ralphb’s xdt99: TI 99 Cross-Development Tools http://atariage.com/forums/topic/233677-xdt99-new-ti-99-cross-development-tools-available/, which does an incredibly good job I have to say. At the moment it doesn’t support outputting a listing file, but I could use WinAsm99 for that, of course. Thanks, I intent to leave the interrupt off, and use your “gameloop” from the assembly thread. When reading the status register, it will be cleared, so an interrupt could be missed, right? -------- Here is the fruit of my work, just a little strawberry though. So far I have Graphics, Music, Keyboard (just the S-key) and the random generator. There's NO gameplay yet, only pressing "S" will give a set of 64 random numbers. System requirements: Extended BASIC Disk drive 32KiB memory expansion F18A (although it works without for now) The program will autostart from DSK1. The source file is attached, so feel free to give lots of suggestions etc. I’m sure things could be done more efficiently. Music and graphics are done by me, myself and I(rene) Except for the character set, which is from some game on the C64. myloop.a99 runme.dsk Edit: Correction, not the fruit of my work alone, but very much of your invaluable help!

Yes indeed, I have to comment them out when I want that.

@Lee Stewart I saw your reply in another thread, about random numbers: http://atariage.com/forums/topic/189117-restless-games/?p=3254385 That gave me some answers already. Thanks for the more in-depth information, so the second routine I just have to call if I want to ensure I get a new random seed, i.e. to get a new set of random numbers? And because I’m only checking the VDP’s status register, I can do that with the interrupts disabled? (limi 0) While debugging it’s often more desirable to get the same set of random numbers, just to see if the program behaves like I expect it to. Then I set the seed to a fixed number. You’re right, but I used it only for debugging reasons, to see the data in the debugger at a fixed place. -------- Next I’m going to implement it in the game, to get a first working version, I hope...

Good Idea, in my game, the player has to press "s" to start the game. That's the point when the seed could be taken from "tick". It completely works to my satisfaction now! However, by the time I read from >83c0, it always has the same value. >8379 on the other hand, is always different. In this version, I have taken the initial seed from >8378, which is >00xx. def sfirst,slast,sload,main sfirst equ $ sload equ $ b @main ** * workspace wrksp equ >8300 * workspace ** * random number memory map stack equ >8320 * subrouting stack, grows down (8 bytes) aorg >b000 * absolute origin at >a000 main limi 0 lwpi wrksp mov @>8378,@rand16 * initialize seed by user keypress li r10,stack * set up the stack pointer mov @rndpnt,r9 * set up random buffer pointer li r1,64 * initiate counter for 64 loops lp bl @grnd * get random number dec r1 * decrease value in r1 by one jne lp * if not zero, return to loop lp p1 jmp p1 * endless loop p jmp p * endless loop ** * general workspace use: * * r9 random number buffer pointer * r10 stack pointer * r11 return address ********************************************************************* * * get random number from 0-3 * grnd mov r11,*r10+ * push return address onto the stack bl @randno * get new random number, stored in rand16 srl r5,14 * divide 16-bit value through * * 16384 to get value from 0-3 mov @rndpnt,r9 mov r5,*r9 * store the random number in inct @rndpnt * * buffer and increase the pointer dect r10 * pop return address off the stack mov *r10,r11 b *r11 ********************************************************************* * * generates a weak pseudo random number and places it in rand16 * * r4 - destroyed * r5 - 16-bit random number and stored in rand16 for next round * randno li r4,28643 * a prime number to multiply by mpy @rand16,r4 * multiply by last random number ai r5,31873 * add a prime number mov r0,r4 * save r0 * mov @tick,r0 * use the vsync tick to mix it up a little andi r0,>000f * check if shift count is 0 jeq rand01 * a 0 count means shift 16, which is a wash src r5,0 * mix up the number to break odd/even pattern rand01 mov r5,@rand16 * save this number for next time mov r4,r0 * restore r0 b *r11 aorg >b0a0 * absolute origin at >a000 rndbuf bss 128 * 64 words random number buffer, with values 0-3 rndpnt data >b0a0 * pointer to the random number buffer rand16 data >ffff * 16-bit random number slast end sfirst Should I place those variables in line 81 and 82 in scratch pad memory, perhaps even those random numbers too (in a more compact format)?

I like your electronic gear and your early computer kits! Wow! I also have an old dual trace oscilloscope, from HAMEG though. Also the homemeade double sided PCB.

I don't like the German nor the Dutch customs. Both are a pita.

That’s indeed like what I meant. I'll give it a try. Oh yeah, I just commented it out, because I pulled the routines out of SIMON, to isolate this random number issue. It’s going to be in there. I think the initial seed will be from >83c0

Progress on SIMON is pretty slow, but that’s because I’m enjoying the view during the ride. Everything is new, so making graphics, music etc. costs a lot of investigation. I’ve also been working on a much shorter development workflow with ralphb’s cross-development tools. http://atariage.com/forums/topic/233677-xdt99-new-ti-99-cross-development-tools-available/ Basically it’s now as easy as the click on a button, to create EA5 files in V9T9 format, to try them out on the emulator(s) and the real thing. It’s not working 100% every time, but that’s another story. Here I have a little program that generates a list of 64 random numbers from 0-3, each stored in one word, starting at >a000. I know, wasteful, but it’s just for convenience. It uses some code of Matthew180's gameloop, like the random generator and the stack. I’m using a pointer to the “buffer” where the random numbers are located. For the pointer, I’m using R9, but I’d rather use a regular ram location, or even a scratch pad location as a pointer. Despite this is working, I’m not satisfied with the code. Is there a more convenient way to do this? Furthermore, am I using the def’s like sfirst etc. correctly? def sfirst,slast,sload,main sfirst equ $ sload equ $ b @main ** * workspace wrksp equ >8300 * workspace ** * random number memory map stack equ >8320 * subrouting stack, grows down (8 bytes) rand16 equ >83c0 * 16-bit random number aorg >a000 * absolute origin at >a000 rndpnt equ $ * pointer to the random number buffer rndbuf bss 128 * 64 words random number buffer, with values 0-3 *rndpnt data >a000 * pointer to the random number buffer main li r10,stack * set up the stack pointer li r9,rndpnt * set up random buffer pointer li r1,64 * initiate counter for 64 loops lp bl @grnd * get random number dec r1 * decrease value in r1 by one jne lp * if not zero, return to loop lp p jmp p * endless loop ** * general workspace use: * * r9 random number buffer pointer * r10 stack pointer * r11 return address ********************************************************************* * * get random number from 0-3 * grnd mov r11,*r10+ * push return address onto the stack bl @randno * get new random number, stored in rand16 srl r5,14 * divide 16-bit value through * * 16384 to get value from 0-3 mov r5,*r9+ * store the random number in * * buffer and increase the pointer dect r10 * pop return address off the stack mov *r10,r11 b *r11 ********************************************************************* * * generates a weak pseudo random number and places it in rand16 * * r4 - destroyed * r5 - 16-bit random number and stored in rand16 for next round * randno li r4,28643 * a prime number to multiply by mpy @rand16,r4 * multiply by last random number ai r5,31873 * add a prime number mov r0,r4 * save r0 * mov @tick,r0 * use the vsync tick to mix it up a little andi r0,>000f * check if shift count is 0 jeq rand01 * a 0 count means shift 16, which is a wash src r5,0 * mix up the number to break odd/even pattern rand01 mov r5,@rand16 * save this number for next time mov r4,r0 * restore r0 b *r11 slast end sfirst

Awesome that Chris Bobbitt gives all his stuff to the community. That really should happen more often!

Great machine! And great ASUS board, they were exceptional in their time. I still have my ASUS TX97 system.

Again the HFCD. It seems very popular. Are there any other mod’s for that controller? (besides those two on whtech?) Does it take any “old” PC 5.25” and/or 3.5”, DD or HD drive, or does work best with a particular drive? I’m not sure where to look for that kind of information.

I just finished a description: MARC-2 BLOG If you want to know anything in particular, just ask.

I started a blog once, but then never looked at it again. I'm going to change that into sort of a description of MARC-1 and MARC-2.

Wonderfull!!! Thanks for the demo and the explanation.