Which CPU does it actually have?

[42bs]

In my test I did zoom a sprite up and down and it was drawn. So at least the video DMA got the bus:

Edit: Handy will not draw it. It detects an endless loop (I tried to attach the .lnx, but could not:"Error You aren't permitted to upload this kind of file")

	Run $2400
	path "f:\lynx\lynx_asm\"

	ibytes "kingtut.pal"
CLS	db $01,$90,$00
	dw KINGTUT0,cls
cls_x	dw 0
cls_y	dw 0
	dw 160*256,102*256
	db $00
cls	db 2,00,0
kingtut	ibytes "kingtut2"

KINGTUT0	db $C1,$10,$00
	dw KINGTUT1,kingtut
	dw 80,52,0,0
	db $01,$23,$45,$67,$89,$ab,$cd,$ef

size	set 1
x	set 79
y	set 51
count	set 5
KINGTUT1
	REPT 511
	db $c1,$18,$00
	dw *+12,kingtut
	dw x,y,size,size
size	set size+1
count	set count-1
IF count=0
x	set x-1
y	set y-1
count	set 5
ENDIF
	ENDR

	REPT 511
	db $c1,$18,$00
	dw *+12,kingtut
	dw x,y,size,size
size	set size-1
count	set count-1
IF count=0
x	set x+1
y	set y+1
count	set 5
ENDIF
	ENDR


KINGTUT1024	db $C1,$18,$00
	dw KINGTUT1,kingtut
	dw 80,52,0,0

Edited October 2, 2018 by 42bs

[ThomH]

So if Mikey is "asleep" and Suzy has the bus, Suzy will not relinquish the bus in the face of an interrupt. That is a troubling issue to mitigate... At some time Mikey needs to get the bus back in order to grab data to draw the screen, or once this happens does the screen just go black?

 

I believe the opposite; the documentation states that "The interrupt signal comes from the timer when ... This signal then requests the bus control circuit to give the bus to the CPU. If the CPU already has the bus, then this function causes no delays. If Suzy If Suzy has the bus, then the maximum Suzy latency time could be incurred." so you just may not wake up quickly.

 

Further supporting evidence:

• the raster bars in the background of Shadow of the Beast (which even the latest Mednafen still doesn't reproduce stably);
• anecdotally, a very poor attempt I once made at raster bars, which completely destroyed my sprite output;
• the fact that SPRGO offers feedback — "Write a 1 to start [sprite drawing], at completion of process this bit will be reset to 0. Either setting or clearing this bit will clear the Stop At End Of Current Sprite bit." (whereas obviously if the CPU could not awake until Suzy was done, no declaration of state would be necessary); and
• the slightly awkward documentation of WAITSUZY, which: "puts the CPU to sleep which allows the sprite engine to run; it returns control to you only after the sprite engine is finished" (and is entirely different from BLL's WAITSUZY, which just spins on the maths flag).

Edited October 2, 2018 by ThomH

[ThomH]

So, you haven't checked out the Jaguar

I find the Lynx docu very much complete. Exact timing information is missing, but one should not rely on this anyway.

 

Being primarily an emulator author [of no significance], I may be viewing this from the other side of the spectrum:

• lack of in-depth documentation makes it an extraordinarily difficult platform to build a realistic model of;
• this is reflected in the fact that even with only 73 commercial titles, there still isn't an emulator that runs all of them completely without issues; and
• the consequence of it is that development is very difficult. If programming for something like a C64, a modern emulator is safe to trust to complete 99% of the job, but on a Lynx I would nowadays be reluctant to write almost anything without verifying it on real hardware regularly.

So my argument would be: the absence of exact timing information that can be relied upon is problematic for potential authors of new software because it restricts the tooling.

 

I am absolutely able to believe that the Jaguar is an order of magnitude worse but, no, I've no direct experience.

[LordKraken]

 

 

on a Lynx I would nowadays be reluctant to write almost anything without verifying it on real hardware regularly.

 

I confirm that, there's always a new surprise

[oziphantom]

Or I make my code so middle of the Road, that it doesn't matter. hopefully.