Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Asmusr

Members
 View Profile  See their activity

  • Content Count

    4,006

  • Joined

  • Last visited

  • Days Won

    13

Posts posted by Asmusr

  2. Posted

    Are all your boards spoken for, or is there a chance of acquiring one? Happy to pay the going rate plus shipping to the UK. Either a built-up board if you've already bought all the parts, or a bare board.

     

    Stuart.

     

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

  3. Posted

    Boulder Dash=Rock Runner. The version titled Boulder Dash was for the Mini Memory (making it one of the great reasons to have that cart) and sold by Legio Computing Centre in Holland. Asgard asked the Eric LaFortune if he could port it over to the E/A environment so that they could sell that version in the US. As Chris Bobbitt was worried that the name would cause copyright issues, he also asked Eric to change the name. Eric pops in here now and again, though he hasn't posted in a long while. He's a nice guy that I talked to several times while I was in Europe long ago.

     

    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.

  7. Posted

    I received a small shipment of 64K boards today from http://imall.iteadstudio.com/

     

    post-35226-0-84179100-1382467010_thumb.jpg

     

    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...

    • Like 4

  11. Posted

    Beautiful! Regarding the GPU emulation in Classic99, it runs the exact same code for the basic functionality, so, for instance, MOV R11,*R10+ should work fine, it's used in many places.

     

    However, although I've implemented all of the modified GPU instructions /none/ of them have been tested. I have the information I need to make a proper spec for each of them, but no time. I'd have expected the stack instructions to work, but I took at guess at how they worked when I did the implementation and did not yet go back to verify them, so... if they are broken I'm not too surprised. F18A parts in Classic99 are all still in the "hack" phase, unfortunately, even the register unlock is not correct, it's just there as enough to be able to single-step through GPU code.

     

    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.

  14. Posted

    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?

  16. Posted

    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

    • Like 2

  17. Posted

    Rasmus, my only weird question on Stargames: I wonder if they have permission from Jaime to reproduce his devices--or if they just purchased them from him in bulk quantities? Since Jaime rarely produces more than a few at a time, I'm suspecting they are building them on their own (this is not a hit on them either here, just a question that popped up in my mind when I looked at their site, since it didn't specify).

    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.

  19. Posted

    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

    • Like 2

  20. Posted

    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?

  21. Posted

    I experienced similar, and think I supplied pictures (earlier in the thread... I am not good at searching.)

    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.

  24. Posted

    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
    • Like 2

  25. Posted

    Actually, thinking about it--the Wiesbaden Supermodul II does have 4 banks of RAM (and 5 banks of GRAM). It lets you load your code with the memory unprotected and uses a physical switch to write protect it when you want to run it without overwriting it. I may have to ask Sven Dyroff if he'll let me make more of them, as they are a really good development tool. The board isn't too hard, as I have printouts of the original layouts and can redo them in Express PCB. I may want to eliminate the stack of 32Kx8 chips and replace it with a 128Kx8 chip though to make assembly a bit easier. . .even if that does waste a bit of the space because it isn't set up to use additional GROM bases.

    Yes that would be a really great development tool. I for one would be very interested.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...