All Activity

Most likely, everything but the 320k memory card will work. Depending on how the 256k upgrades were implemented, the 320k memory card could work, too.

I created a whole thread for this but I thought it would be appropriate if I left it here also. If you need your INTV console repaired, modified, etc. I recommend Jesse at Ivory Tower Collections. He's done two different INTV consoles for me via RGB board upgrade and I couldn't be more pleased. He also repaired some INTV controller's for me, two Sears models and two Flashbacks. He has my highest recommendation. Keith 🕹️

Something has just occurred to me... Both of my XL's (600 and 800) have 256K upgrades installed in them. Is this going to create problems with my 1090XL? David

If you need your INTV console repaired, modified, etc. I recommend Jesse at Ivory Tower Collections. He's done two different INTV consoles for me via RGB board upgrade and I couldn't be more pleased. He also repaired some controllers for me, two Sears models and two Flashbacks. He has my highest recommendation. Keith 🕹️

If you need your INTV console repaired, modified, etc. I recommend Jesse at Ivory Tower Collections. He's done two different INTV consoles for me via RGB board upgrade and I couldn't be more pleased. He also repaired some controllers for me, two Sears models and two Flashbacks. He has my highest recommendation. Keith 🕹️

Unfortunately I will not be able to make, well I arrive back at home around midnight from France after a 5 hour train trip. In Eastern time I get back home around 6pm , if I still have some energy left in me , I might join if the call is still ongoing.

Up for grabs is steam key for a VR title "A Fisherman's Tale". If more than one person show's interest, I'll drop the names in a hat and do a drawing for the winner. Good luck to whoever is interested.

Isn't it possible you forgot to collect the special item at the first screen with the lander? Collecting it is reflected by an icon above the score counter.

Cubis added! @saxmeister

I ordered Bentley Bear’s Crystal Quest back in January and got it in March. That was much faster than I was expecting because of the backlog created by the last chance sale. I think Al is making progress and shrinking that backlog. This is of course a completely different problem than the XP line which I haven’t bothered with. My standard Editions of Bezerk enhanced and Mr. Run and Jump arrived quickly after I ordered them and I’ve had zero problems with what I’ve ordered direct from Atari and through Amazon. The XP line is probably a lost cause and I expect it to just be canceled eventually which doesn’t hurt my feelings any. The standard editions and everything in the plus line are going just fine. 👍🏼

@OLD CS1 I'm interested in buying the FORTH and TE Protocol booklets. Let me know if they are still available. Thank you!

Is it “next week”? 😜

The basic idea is right and this is used when a character has one or more animations with a huge number of frames (and usually of large dimensions) that all the frames can't stay in memory at the same time. But you can't load a data array with lynx_load(), you load a cart segment in memory with lynx_load((int)SPRITEFRAME_X_FILENR), and usually you don't need to load every frame, and If the character animation has N frames per second and the game runs at X FPS, you need to load a new sprite frame every X/N (e.g. with a character with 4 frames per second and the game running at 20FPS, 20/4=5, you need to load a new character frame every 5 seconds) Usually I adopt two tricks when loading resources from the cart this way for saving some ram and computing time. The first one is to put the sprites frames in subsequent cart segments, and to use for all of them the same pointer variable name, this way I don't have to change the value in the SCB.data field when the sprite changes (the compiler throws several warning for duplicate variable names, but as long as you know what your doing everything works fine). It also saves a lot of memory because you don't have to define an array with all the pointers to the several sprite frames. The other trick is to use lynx_load with the pointer to the first frame segment + an unsigned char offset to the number of the sprite frame to load, i.e. lynx_load(((int)SPRITEFRAME_0_FILENR) + animframe), this way you don't need to have an array with all the segments indexes, but the cart segments must be in the same order of the sprite animation frame. I hope this helps.

Hmm... better! Not perfect, but a big step up from the likes of Omega Race, Space Fury, and the Dondzila port of Star Castle.

I would say, think in terms of effective address and operand. For source and destination. The effective address is where the CPU will fetch a word from for the source or destination. Every addressing mode is decoded to an effective address first (Immediate is a special case) as in this table: addressing mode effective address register Rn WP + 2*n indirect *Rn word in Rn symbolic @>FFFC >FFFC @LABEL address of LABEL indexed @TBL(R5) address of TBL + word in R5 If you think of the operand as always the effective address of source (or destination), not the value, you won't make the mistake of supposing that the hex you see (like @>FFFC) is the value you're using. It's always going to be the address of the thing. From another point of view, every source or destination addressing mode is decoded into an effective address in memory, not a value. The value always has to be fetched after that address is decoded. Now the special case in Load Immediate (or Add Immediate, etc) LI R10,>1000 The source operand is the value >1000. But what is the effective address of >1000? The definition of Immediate mode is: the source operand is the next word pointed to by the PC. So there: the effective address is the value of PC. And Immediate still fits into the definition of effective address. If you know that PC is called a hardware register, Immediate Mode is another Register Indirect AutoIncrementing: *PC+ Addr Data Comment PC 024E opcode for Load Immediate into R10 PC+2 1000 the value comes after the instruction It's helpful to study the "9900 Instruction Set" for definitions of the shorthand S,D, WP, SA and so on. Hope this clarifies. Hope it does not confuse further!

Well, I got inspired this evening after work. I lost the art files to my mini box, but found a saved picture of the design and began rebuilding the original file as best as I could. Plus I redid the artwork to River Raid as well. I took the measurements from the sleeve of my copy of Mr. Run And Jump.

ADSTEST.S Assembly language source showing how to detetct the AdSpeed ST and switch its speed. * ADSTEST.S: routines to detect the presence of an AdSpeed ST and * switch its speed * count of < threshold means 8 mhz, >= means 16mhz * this value may be adjusted, but that shouldn't be necessary threshold equ 550 * set AdSpeed ST to 16 MHz .globl SET16 .even SET16: move.w #0,$f00000 rts * set AdSpeed ST to 8 MHz .globl SET8 .even SET8: move.w #0,$f10000 rts * enter supervisor mode .even super: clr.l -(sp) move.w #$20,-(sp) trap #1 addq.l #6,sp move.l d0,savessp ;save supervisor stack pointer rts * exit supervisor mode .even xsuper: move.l savessp,-(sp) ;restore supervisor stack pointer move.w #$20,-(sp) trap #1 addq.l #6,sp rts * test for existence of AdSpeed * out: d0= 1 if found, 0 if not .globl ISADS .even ISADS: bsr super ;must be in supervisor mode bsr gcount ;get count of divides in tick of cmp.l #threshold,d0 ;200 Hz counter. Determine present blt.s is8 ;system CPU speed move.w #1,tspeed is8: move.w sr,d5 ;save some stuff move.l a7,a5 move.l 8,old8 move.l #unpatch,8 ;patch address error vector tst.w tspeed bne.s t16 bsr SET8 ;to see if AdSpeed ST exists, try bra.s setex ;setting to current CPU speed t16: bsr SET16 setex: move.w #1,exists ;if no error, got here and set this flag unpatch: move.l a5,a7 ;if an error, returned directly to move.w d5,sr ;here move.l old8,8 bsr xsuper ;leave supervisor mode clr.l d0 move.w exists,d0 ;exit with boolean in d0 rts * out: d0 = number of divides in one tick of 200 hz counter gcount: clr.l d0 ;d0 = counter move.l $4ba,d2 ;d2 = start tick tick: cmp.l $4ba,d2 ;wait for a new tick beq.s tick move.l $4ba,d2 loop: move.l junk,d1 ;do divides until start of next tick divu #2,d1 addq.l #1,d0 move.l $4ba,d1 cmp.l d2,d1 beq.s loop rts junk: dc.l $80000000 exists: dc.w 0 savessp: dc.l 0 tspeed: dc.w 0 old8: dc.l 0 .end counter move.l $4ba,d2 ;d2 = start tick tick: cmp.l $4ba,d2 ;wait for a new tick beq.s tick move.l $4ba,d2 loop: move.l junk,d1 ;do divides until start of next tick divu #2,d1 addq.l #1,d0 move.l $4ba,d1 cmp.l d2,d1 beq.s loop rts junk: dc.l $80000000 exists: dc.w 0 savessp: dc.l 0 tspeed: dc.w 0 old8: dc.l 0 .end

That did the trick, just compiled and tested MDOS. Thanks mate, much appreciated.

EDIT: Oops that's for ICD HD Driver. CACHEOFF.PRGCACHEON.PRG

This completely sounds like a dirty cartridge slot to me. Maybe a spray of some deoxit in the slot would solve the problem.

If you are running MAME with the standard 512K and 64K SRAM, check your AUTOEXEC for TIMODE, TIMODE2, SPOOLER, and/or a RAMDISK. The ANSI driver will also consume 16K. This picture from your earlier post strongly suggests that you are reserving memory as GenWIPE is only finding 9 pages (72K) to clear. This is barely enough for the programs to run much less to compile large sources. The MDOS program image is 136k so you probably need 200k free. Type MEM at the command line to see available memory pages.

Atari ST Interfaces & Connectors FD Connector - DIN 14 Female Pin Signal Name 1 Read Data 2 Side 0 Select 3 Logic Ground 4 Index Pulse 5 Drive X Select 6 Drive Y Select 7 Logic Ground 8 Motor On 9 Direction In 10 Step 11 Write Data 12 Write Gate 13 Track 00 14 Write Protect

I did some more troubleshooting and individually compiled the source files listed in !DOIT (which I assume is generated by MAKE?); these 3 all give an "out of memory" error: BIN\ASM HD\COPYS,OBJ\HDOBJ,,RCO BIN\ASM L8\FDC-SRC,OBJ\OBJ1,,RCO BIN\ASM L6\XOPS-S,OBJ\XOPS-G,,RCO I am compiling under MAME / MDOS 7.45; are there any memory constraints with this combo you think?

Just now I reflashed the USB firmware and ran the test again and same result. Fails on the first 7 pages of the test. Note I always flash with the Pico PEB disconnected from the TI, which requires removing and reinserting the Pico. So I tried on my beige (non-QI) TI and same result there, failure. I pulled out a different Pico PEB and loaded the USB firmware on that. Fails on both TIs. I changed to the prior version of the firmware on both Pico PEBs and the SAMS tests pass on both TIs. If you would like to see another test, let know. For now the prior firmware is great for me, so I will use that (outside of testing of course). Edit: all tests here were done at 250 mhz, 1 NOP

Thank you @Peri Noid, I'll update community with results soon 🙂 BR,