Asmusr

Looks like just another screen capture of Classic99 ... ... but wait, there's something strange going on.

It's somewhere in this thread: http://atariage.com/forums/topic/185936-at-least-dsk-image-from-my-collection/?do=findComment&comment=2342807

It's too early to say. Send me a private message in a month or so. Right now they are my most precious toys.

Interesting. Is the version on Boulder Dash for Mini Memory still to be found? I have a Mini Memory but I have never really used it.

Thanks, I actually didn't know about the Tab menu (and that you had to press ScrollLock first), I'm usually using the QMC2 front end.

Is it possible to disable the 32k in MESS or Classic99 to test how a cartridge would work? I have only found ways to do this in v9t9 and Win994a. Thanks, Rasmus.

From Gerber. Only thing I had to do was change the file name extensions of Jon Guidry's files.

I received a small shipment of 64K boards today from http://imall.iteadstudio.com/ Beautifully made with perfect fit, blue finish, silk screen layer and plated though holes. And at $35 for 12 PCBs I think it was a real bargain (the cost was more like $100 including shipping, customs and tax, but you can't blame the company for that). I don't have any EPROMS yet, but hope to get some within a few days. Can't wait to insert my first command module...

The sound problem is fixed, the CRU bit is working, and my GPU demo is working! All my wishes come true.

Sorry.

Thanks, now it's compiling, but the linker wants ddraw.lib. This is no longer part of the DirectX SDK so I don't know where to find it.

As far as I can tell from the debugger MOV instructions with post increment are not incrementing. If you run my demo and set a breakpoint at >2800 you only have to single step 8 times to get to a post incrementing instruction. Since the GPU doesn't have a workspace pointer (I assume the registers are internal?) I would expect that the emulation has to be slightly different from the ordinary CPU.

I wouldn't want to struggle with Zaxxon on the 9918A. The graphics in the Colecovision version looks quite impressive, but slow, and the gameplay should be awful. You could probably make a really nice Zaxxon using the F18A. Commando actually seems more a reasonable project for the 9918A although it's 3 years younger than Zaxxon.

It has a vague resemblance to Rock Runner

Tursi, I'm trying to build Classic99 from the source of the latest version, but I'm getting these error messages: 1>d:\ti-99-4a\classic99\src\console\tiemul.cpp(1567): error C2065: 'ID_DISK_CORRUPTDSKRAM' : undeclared identifier 1>d:\ti-99-4a\classic99\src\console\tiemul.cpp(1570): error C2065: 'ID_VIDEO_ENABLEF18A' : undeclared identifier 1>d:\ti-99-4a\classic99\src\addons\windowproc.cpp(1085): error C2065: 'ID_DISK_CORRUPTDSKRAM' : undeclared identifier 1>d:\ti-99-4a\classic99\src\addons\windowproc.cpp(1085): error C2051: case expression not constant 1>d:\ti-99-4a\classic99\src\addons\windowproc.cpp(1090): error C2065: 'ID_DISK_CORRUPTDSKRAM' : undeclared identifier 1>d:\ti-99-4a\classic99\src\addons\windowproc.cpp(1092): error C2065: 'ID_DISK_CORRUPTDSKRAM' : undeclared identifier 1>d:\ti-99-4a\classic99\src\addons\windowproc.cpp(1220): error C2065: 'ID_VIDEO_ENABLEF18A' : undeclared identifier 1>d:\ti-99-4a\classic99\src\addons\windowproc.cpp(1220): error C2051: case expression not constant 1>d:\ti-99-4a\classic99\src\addons\windowproc.cpp(1225): error C2065: 'ID_VIDEO_ENABLEF18A' : undeclared identifier 1>d:\ti-99-4a\classic99\src\addons\windowproc.cpp(1227): error C2065: 'ID_VIDEO_ENABLEF18A' : undeclared identifier Is it possible that resource.h is out of date?

I think CALL, RET, PUSH, POP are working in Classic99 - it's something else that goes wrong.

With a proper wait for vsync the demo becomes a lot smoother. Now the GPU is busy waiting much of the time. By drawing the objects from top to bottom I have enough time to blank the bitmap screen (pattern tables) each frame and draw it again before the 'beam' catches up, but to implement a 3D engine, for instance, I think you would have to use double buffering and the F18A bitmap layer, and this again means that you would only have enough VDP RAM to draw on half of the screen. gpulines.zip

The fact that they have 2-3 days delivery time (not weeks or months) on the nanoPEB does indicate that they don't get them from the US.

You need the 994agr38.bin ROM. What is it that fails to start, the whole machine or specific software?

I wanted to see what the GPU was capable of, so I converted my first TI demo to run on the GPU. The original demo can be found here: http://atariage.com/forums/topic/162941-assembly-on-the-994a/page-9?do=findComment&comment=2730495 Basically it's just drawing lines in bitmap mode. It's not using the PIX instruction or the bitmap layer. The original demo was running at 2-3 frames per second. On the GPU it's more like 200 FPS! If you look at the code, everything from AORG GPUPRG is running on the GPU. I try to wait for vsync/blanking (source code lines 278-282), but I don't think it's working. I'm even waiting twice: for blanking, for non-blanking, and for blanking again. Probably some simple mistake. Note that this doesn't run on Classic99. Even if you disable the vsync loop, which I wouldn't expect to work, there are still some problems with the GPU emulation. (I noticed that the instruction MOV R11,*R10+ doesn't seem to increment R10, but I'm not sure.) While the GPU is drawing the lines, the good old TMS9900 is also pumping data to the VDP for the scrolling background. I think it's really cool how this can go on in parallel. A final thing to notice is that I'm using the new CALL and RET instructions of the GPU, which can be entered as BSTK and RSTK in Asm994a. Sorry for the video quality. YouTube has almost destroyed it. gpulines.zip

Thank you, so the VDP registers are mapped from >6000, but where is the ordinary 9918A status register? While we're talking GPU, it can hardly be a coincidence that the op-codes for PUSH, POP, CALL and RET are the same as for the "New Stack Instructions" that are implemented in Asm994A: PHWS, PPWS, BSTK and RSTK (described in Enhancements.pdf): PUSH = PHWS = >0D00 (actually >2C40 for PHWS R0,R0 ???) POP = PPWS = >0F00 (actually >2C80 for PPWS R0,R0 ???) CALL = BSTK = >0C80 (>0CA0 symbolic) RET = RSTK = >0C00 Unfortunately PHWS and PPWS don't seem to assemble as described. They require two operands or you get an error, which is very strange, and the op-codes are different. Any comments?

Your pictures are in post 40. It's really difficult to tell what is going on. My best guess is that a register that controls the name table switching (and there's lots of that in Titanium) is corrupted. I have never seen this myself. The only weird thing I have seen (and this is on my F18A with the old 1.3 firmware) is that the enemy sprites suddenly start moving at near light speed.

How do you vsync from the GPU side? Post #5 mentions blanking at >7001, can you just read that address? Are the status registers memory mapped at the GPU side?

And it also works on my US console with the F18A. Edit: ... and in MESS.

It works for me on my PAL console. In Classic99 it returns immediately. REF VWTR DEF START VDPST EQU >8802 START LIMI 0 LI R1,>0170 VDP Reg 1, Enable IE bit.(mode bits may vary) BLWP @VWTR CLR R12 9901 base cru SBO 2 vdp int via 9901, enable LI R1,60*10 duration in 60th of a second slice WAIT1 CLR R12 WAIT2 TB 2 vdp interrupt? (via 9901) JEQ WAIT2 no, spin and wait SBO 2 enable 9901 int (tests show this may not be needed) MOVB @VDPST,R2 read status to clear 9918 VDP Interrupt DEC R1 counter expired? JNE WAIT1 no, tick off another 60th of a second BLWP @0 END START