Re: DGR...

[BLuRry <brendan.robert@gmail.com>]

On Thursday, November 15, 2012 10:12:47 AM UTC-6, Steve Nickolas wrote:
> On Thu, 15 Nov 2012, BLuRry wrote:
> 
> 
> 
> > Nifty!  Well, the only way to draw is via the DXYN opcode and screen 
> 
> > memory is otherwise not accessible.  That could be rather handy since 
> 
> > you only have to optimize one screen access method (and the clear screen 
> 
> > opcode can be a simple rom call).
> 
> >
> 
> > It makes sense to do a first pass which just plots using rom calls, but 
> 
> > since you can impose a lot of constraints, such as B&W only, you can go 
> 
> > back and optimize a lot of things to make your own quick draw routine 
> 
> > which draws two pixels at once and so on.  It would be a better use of 
> 
> > time to focus on the main loop and less time worrying about all the 
> 
> > specifics like sound (though timers will be a big deal... you could use 
> 
> > the //c and //gs VBL interrupts but for the //e you'd have to poll the 
> 
> > VBL in your main loop.)
> 
> >
> 
> > -B
> 
> >
> 
> 
> 
> The "main loop" is already coded and mostly functional on another 
> 
> platform; I cannot test the Apple code because I'm "flying blind".
> 
> 
> 
> -uso.

I felt that way when writing the 65c02 core of Jace.  I wouldn't have gotten far without another solid emulator handy (ahem... AppleWin) to provide a useful benchmark to ensure the CPU was tracing the execution path correctly.  If you can, figure out a way to step the execution of a very small program and track the basics (registers, memory changes, program counter location) to ensure it is following the right path.  

Either way you'll be in a chicken-and-egg situation when you want to test the graphics code, and the graphics output doesn't do anything to the state of the running program unless there is detected collision (VF is set to 1).  So printing "Hello world" won't alter VF and you can test the execution of a hello world program without having working graphical output -- but you will need some primitive way to trace the program execution.  Once you see the program running, then you can leap to graphics output with some degree of confidence that any future error will be from new code and not some other untested part of the emulation.

-B