Coincidentally I've just recently written a ZX81 emulator for the PC. The way it uses refresh cycles to create a display counter is very clever indeed and definitely what I found most interesting. I didn't end up doing much prying into the software side of things since it was a PC-side thing, but I guess a lightweight handler was necessitated by the way the slow mode timer was added to the ZX80 hardware?
Have you considered giving DOSBox a go for TASM? It interacts fully with the native filing system so you just end up with a cmd.exe alternative that runs a different set of software. On 2 Apr 2012, at 16:32, "Aleš Keprt" <a...@keprt.cz> wrote: > Actually there is a commented source code on Simon's web. The viewer is > quite straighforward, all the colour magic lies in the converter. ;-) > I am now planning to create a zx81 emulator, and that computer is quite > interesting in that it doesn't push all registers to stack on interrupt. It > means that some registers can't be generally used when interrupt is enabled, > but the benefit is that the interrupt handelr routine is faster to start. > This zx81-way it would probably be possible to change more colours per > scanline. > > That brings me to the question if there exist 64bit TASM compiler. I always > used TASM with Z80 mactors to compile my programs, but now I can't run TASM > because my version is apparently a 16bit exe from MS-DOS. I would probably > need to find at least some 32bit edition, if that's possible. (I don't have > any experience with Python and I am not generally happy to install Python in > order to run Z80 crossassembler once in a while.) > A. > > -----Původní zpráva----- > From: Thomas Harte > Sent: Tuesday, April 03, 2012 12:58 AM > To: sam-users@nvg.ntnu.no > Subject: Re: SAM HAM viewer > > I've seen something similar on the Atari Lynx, which also has a 4 bit > frame buffer, the only difference being that I think that used a tight > loop of something like (i) load next palette index, next colour and > next delay length; (ii) push colour to palette index; (iii) perform a > busy loop of the desired length; (iv) repeat. The loop was > synchronised once with vertical retrace and timings were such that a > degenerate case was to change the entire palette once after every scan > line but you could instead, say, change a single palette index several > times over the course of a single scan line, or anything in between. > > A better adaption for the Sam might be to allow palette and mode > changes, and for simplicity to add a delay length that just means to > wait until the next vertical retrace? If you have portions of the > image with only four colours (especially once the colour aliasing > forced by the 128-colour palette is accounted for) then switching to > mode 3 for a portion of a line could be the smarter thing to do, and > would presumably cost basically nothing to implement? > > In terms of image conversion, I guess a heuristic would be the thing. > It feels like, even at Sam size, an exhaustive search could take > forever. > > Of course, I didn't disassemble Simon's fantastic work so it's > possible he's way ahead of me on this one. > > On 1 April 2012 18:05, Aleš Keprt <a...@keprt.cz> wrote: >> Oh yes, this is nice. I saw similar things in the past, AFAIR this was >> published on some disk magazine back in 90's. But it will be hard to find >> it >> now. >> >> So how many colours are possible per line in this format? Or what is >> possible in this picture format? >> >> Also, I think that the converter could possibly de-noise the picture >> before >> or after the conversion. Or something like that. Because there are too >> many >> dots visible in places where there should be no dots. This is good in high >> resolution graphics like when printing on printer in 600 DPI, but doesn't >> look too well on Sam. Especially in emulator with crisp LCD display. ;-) I >> think the whole de-noising process is extremely important when converting >> to >> low resolution and low bitdepth. And each single picture needs a different >> values for the algorithm, so maybe there should be some kind of WYSIWYG >> editor or something where users could change some settings and see the >> result immediately in order to find the best settings for each file. ;-) >> Maybe a genetic algorithm could help to find at least some local optimum
