Spectrum emulator

[buggage]

So I take it spectrum programs (for emulation) are is stored in some type of hunk based data image where there's a screen shot in it ?

No, the loading screens are built up from data being loaded from the file - a line (monochrome pixels IIRC) at a time, then coloured in at the end. I suspect that this is not happening here, but rather a screenshot of the loading image is being displayed - ie, not really loaded in the same way as a Spectrum did it. Like you say Kevin, a mock up (for now hopefully).

I had a routine many years ago that allowed an Amstrad CPC to load in a Speccy screen properly, but it's long since lost. It wasn't difficult to do, although it was Z80 code, as the Amstrad used Z80 too.

[EDIT] Here's a video of a game loading - http://vimeo.com/43676648  It's different to some games, but similar enough to get an idea how it works.

[kevin]

No, the loading screens are built up from data being loaded from the file - a line (monochrome pixels IIRC) at a time, then coloured in at the end. I suspect that this is not happening here, but rather a screenshot of the loading image is being displayed - ie, not really loaded in the same way as a Spectrum did it. Like you say Kevin, a mock up (for now hopefully).

   yeah, had a look see at the TAP file format a few hours ago.   Makes sense that if any hunk is loaded directly before/into video memory, the image will appear to spool on (for want of better word)

[baggey]

You don't miss nothing!

yeah the text information is some mock up code. Just made to test the layout of the Speccy user interface.

whats happening is im loading the screen buffer which is (16384 or 4000) and ends in (22527 or 57FF) the next 768 Bytes are paper and Ink colour's. Starting at (22528 or 5800) ending at (23295 or 5AFF).

The .scr file is the bulk data as you call it for the screen display and attributes file. 6144 for display 768 for ATTR file making an .scr file 6912 Bytes all told!

World of Spectrum is a good site http://www.worldofspectrum.org/

So im testing the loading of .scr's. Putting the information into a look up memory bank. so when the screen emulator part checks the display bank in puts all the information onto an image of 255,192 with the relevant ink and paper palette.

Using fastdot to draw the actual size of 49152 pixel's and drawrotatedimage to blow up and stretch!

not all the screen is changed at once so im using a look up to see which line has changed and display it! So this should help speed it up a bit. But not sure when scrolling games are loaded wether it will be to slow!?

Threre's only one way to find out thou!

Emulating the 16K and 48K is going to be my main emulation as the 128K uses ram pages etc which will be difficult!?

I believe the Z80 core has around 720 instructions its going to be alot of typing!

I already have images of the ROM starting at 0000. Im going to be concentrating on the z80 snapshot files. Which are the RAM of the game! But sorting the header of this is going to be difficult, As will have all the flags, stack pointers, registers and program counter information etc. So it will run at that point in time when the snapshot was taken.

summary

Its a genuine spectrum .scr being loaded stored in a memory bank just like the spectrum and using an x,y coordinate system referenced to display address and and ATTR file!
so i can change pixels anywhere they occur and of course colour.

I could simulate a loading screen by starting at 16384 and work through each byte, finishing at 23295 of the display just like a spectrum game loading! ANY REQUEST'S for this in the final version?

My next step is to use the .scr's to select the game or file name. display the .scr loading screen wait to run is clicked. Then start the game. But i want to scroll scr's in the file select. Just like the Ipod's.

[buggage]

Sounds like you're going in the right direction. Keep it up :)

[kevin]

Z80 Instruction Set links.
http://map.grauw.nl/resources/z80instr.php
http://www.ftp83plus.net/Tutorials/z80inset_fullA.htm


Ignore Just testing embedding vimeo videos.  (See here for a how)
http://vimeo.com/43676648

[kevin]

yeah the text information is some mock up code. Just made to test the layout of the Speccy user interface.
whats happening is im loading the screen buffer which is (16384 or 4000) and ends in (22527 or 57FF) the next 768 Bytes are paper and Ink colour's. Starting at (22528 or 5800) ending at (23295 or 5AFF).

The .scr file is the bulk data as you call it for the screen display and attributes file. 6144 for display 768 for ATTR file making an .scr file 6912 Bytes all told!

 I see, so  .scr is common speccy image format then?  Like FLI etc on the C64 (Vic Vision  )

 

So im testing the loading of .scr's. Putting the information into a look up memory bank. so when the screen emulator part checks the display bank in puts all the information onto an image of 255,192 with the relevant ink and paper palette.

Using fastdot to draw the actual size of 49152 pixel's and drawrotatedimage to blow up and stretch!

not all the screen is changed at once so im using a look up to see which line has changed and display it! So this should help speed it up a bit. But not sure when scrolling games are loaded wether it will be to slow!?

   You could cache the frame, but my gut feeling is that would add more overhead than you gain, so it'll probably not be worth it.   Basically the CPU core will execute for bunch of cycles, you 'll no doubt have to emulate the beam position of video hardware, this can be expressed as factor the cycle count per frame.    On a real hardware, each scan line might cost 255 cpu cycles (it doesn't, but for the sake this example), The beam position could then be cheated by simply dividing the cycle count by (cycles per scan line), to the number of scan lines from the system start, then mod it within the vertical blank gap.  

   Knowing the beam position is how to tigger a  video refresh,  the simplest option would be to drop the entire frame in one hit.  Assuming raster programming isn't common place on the speccy (like it is on the c64), then that'd would work well enough.     Moreover, i'm assuming the beam position can be read in software here on the speccy?, if so, then some programs will sit in wait loops when rendering waiting for it reach a scanline.  So you'd need to some emulation of it.    

Emulating the 16K and 48K is going to be my main emulation as the 128K uses ram pages etc which will be difficult!?

I believe the Z80 core has around 720 instructions its going to be alot of typing!

 720 ?  Had a look and there doesn't seem to be that many.

 For paging i'd just copy the banks, which would choke on some programs, but it'd probably work ok as long the app doesn't flip/flop between pages.  Then it'd really choke.  The advantage is that it avoids having a displacement offset every single read/write.  

 Another issue will be shadowing the custom hardware and roms.   Do these overlap ram in  16K / 48K  machines?  

I already have images of the ROM starting at 0000. Im going to be concentrating on the z80 snapshot files. Which are the RAM of the game! But sorting the header of this is going to be difficult, As will have all the flags, stack pointers, registers and program counter information etc. So it will run at that point in time when the snapshot was taken.

  Running a snap shot is really the only option and I wish you luck with that approach,  but I still feel you'll a better chance using a cross compiler and writing/testing each opcode.    

[baggey]

Hi im back,

Knackered from my holiday.

Anyways ive spent a few days getting back in to the program. In the process ive sorted a couple of bugs!

The menu loader with scr files is progressing  :) its about 2/3rd's of the way to completion. This is going to be, were ill release an EXE with files so you can play with the progress so far!

There are a lot of un-documented codes on the speccy Z80. i have some old books from my teenage years that document them all!

Off the top of my head. There are 2 8-bit register's which can be used to address 65535, i think which makes the 48k ram with the rom. On the 16K it ony addressed the 16k ram that was available!

Now the 128K speccy isn't something i was familiar with. so for me to start a 128k emulation is going to be another big learning curve!?

The SCR format is a PC version of the SCREEN$ on the speccy.

Im hoping to have this finished for the weekend!

Baggey

[baggey]

Well Here it goes!    ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D

As promised.

Something to playwith

Release 0.0sp

[baggey]

And here is the second part! just merge over the first file.

There may be some teething problems and there may not?

version 0.0sp part2

Enjoy Baggey  ;)

[baggey]

Hi,

These zip files need to be extracted to "C:\"

Ive now checked the downloadz

As long as you extract both files to "C:\" in winRAR. You will find on drive C:\. A folder called "spectrum_playbasic"
Click on this folder to open, now run the exe!

kind regards baggey

[kevin]

and the keys are ?

[baggey]

Use your mouse! When your in full Screen mode press escape key to go back to monitor mode!

[baggey]

I am now working on the screen display emulation a bit more! some of the loading screens should have flashing items. Such as "press any key" etc.
This needs to be bought to life.

The famous screen of "manic miner" flashed the words "manic" and then the words "miner". This is to do with (bit7 or And 128) of the ATTR display byte file. The inbuilt routine in ROM flashes the ink and paper colours respectively.

Ive also found a few more bugs which ive sorted on the screen display emulation as well.

Also to do with the screen display im going to work on the Display to simulate the loading of the SCR's just for that RETRO feel!

When ive addressed these items i shall upload another release  ;D

Kind regards Baggey

[baggey]

Well ive got the flashing working nearly 50%

"Manic Miner" in my opinion is the best one to start with so.

Here is "Manic Miner" scr

and the latest EXE which i suppose is a beta but im not calling it a release!

Baggey

[baggey]

Hi KEVIN,

Check your Email

Baggey