Hello guys,
As a newcomer in this forum, let me introduce myself : My name is Thomas, and (as lots of you I can believe) I used to have a CPC 6128 in the late '80, when I was about 13.
Since that day, I stayed in computer (I actually work on software by now)...
And at the end of last year, I decided to code my own emulator, to bring back these old memories (I don't have any CPC at home, due place, wife and kid's factor).
I know lot's of emulator exists, but it was like a challenge to make my own work (and I must admit that it's a big thing to start to run old games on "my" hardware).
By now, my emulator (call it "sugarbox", until I find a better name) run most of non-protected games, if they don't intend to much on hard timing of CRTC and gate array..
So that's the point : I try to find informations about timing and FDC.
1/ The Z80 timings : I fond on this forum some informations about various tests. Lot's of them are now passed, but one of them since to be a bit far from my understanding : It's the "Interrupt Wait test", from the "plustest" of Richard Wilson. I don't understand what is supposed to be test, and how (so, i don't have a clue about why some opcodes are ok, and some other aren't...).
If anyone can give me some advice about it, it would help me a lot !
2/ The infamous FDC.... I try to understand what kind of datas are returned by this command : I understand that it returns the track data, from first sector to last. So, I assumed that it begin at the first data of the first sector, but I don't know how are manages other "extra" data, between two sector : Does it return everything until the enf of the track ? or some of these datas are not returned ?
3/ The copy protections... I found also some words about them, but nothing about how it is supposed to work... Does these informations exists ?
I'm currently trying to make work "Chicago 90'" and "Le Necromancien", which are maybe a bit tough for a first try....
I'm joining a very alpha of this emulator, in case anyone want to give it a try (or want to test this Interrupt Wait test and give me a clue !)
Be aware it's far from stable, not really user-friendly (in fact, not user friendly at all), and not really fast.
It's designed for windows, and should work with version from XP until 7 (not tested on 8)
Unzip and run "Sugarbox.exe"
It support command line arguments :
sugarbox [-drivea path_of_dsk] [-command "command to start"]
sugarbox.exe -drivea "c:\dsk\ch90.dsk" -command run"ch90"
Thanks for your attention
[attachurl=2]
Hello!
I suggest you to use the M.E.S.S. FDC 765 emulation part, as it's more accurate than 90% of the existing CPC emulators and allow to run protected games as well.
Quote from: Lone on 15:45, 08 July 13
1/ The Z80 timings : I fond on this forum some informations about various tests. Lot's of them are now passed, but one of them since to be a bit far from my understanding : It's the "Interrupt Wait test", from the "plustest" of Richard Wilson. I don't understand what is supposed to be test, and how (so, i don't have a clue about why some opcodes are ok, and some other aren't...).
It's caused by the way the CPCs hardware stretches the timings of the instructions.
CPCs hardware forces all memory accesses to be on 1microsecond intervals.
Some instructions don't fit into this pattern, and have "extra" time at the end of them - one of these is INC BC. It takes 1us to read the instruction, and less than 1us to process it. Leaving some time left over. Normally this time is used up.
But, when an interrupt comes, it can be acknowledged immediately before the next 1us comes. The interrupt uses up some of this time, and so it can appear to happen earlier than expected.
On other instructions there is no free time, so the interrupt is forced to take 1us cycle for acknowledge, and we see that.
This explains these differences.
If you look at the official Zilog instruction manual and see how the instructions are divided into T states, you can guess at which will do this and why.
Quote from: Lone on 15:45, 08 July 13
2/ The infamous FDC.... I try to understand what kind of datas are returned by this command : I understand that it returns the track data, from first sector to last. So, I assumed that it begin at the first data of the first sector, but I don't know how are manages other "extra" data, between two sector : Does it return everything until the enf of the track ? or some of these datas are not returned ?
Read the official FDC datasheet, then read the data sheets of the compatible FDCs this will tell you quite a lot, but also be prepared to make a test program because there are some things that are not described in the documents. When I made Arnold, I was already familiar with how the FDC worked so that solved a lot of things, but then when I made some tests I found a lot more interesting things.
Quote from: Lone on 15:45, 08 July 13
3/ The copy protections... I found also some words about them, but nothing about how it is supposed to work... Does these informations exists ?
I'm currently trying to make work "Chicago 90'" and "Le Necromancien", which are maybe a bit tough for a first try....
No information exists to explain exactly how these work.
Good luck with Le Necromancien, this requires you emulate the lowest level MFM disc structure to read it correctly. I would start with something a lot more simple and work from there.
Quote from: Lone on 15:45, 08 July 13
Thanks for your attention
Continue with your work, because it will also help if you want to use the knowledge to make games and demos for this computer :)
Hello again....
First, thanks for your responses.Some time passed, and I at least had the time to try some tricks, to fully understand how this FDC works.For the memory, here is what I found out.
I finally manage to run "Chicago 90", with the original game dump (GAP protection inside), thanks to the coming back of cpc-power ( [size=78%]http://www.cpc-power.com/index.php?page=detail&onglet=dumps&num=548[/size][/font] ). I had some problems with it, due to my handling of the overrun data (data made ready by the FDC, but not read by the CPU).
When I finally added a fifo buffer (with a size of 16 bytes... Really empiric value : 10 bytes causes overflow, and 16 seems to be enough in this cas of figure), to hold data, my problem disapears, and the game loads then run correctly.
So it seems that I finally found a solution.... But what's a bit unexpected, is that I didn't read anything about any kind of buffer within the FDC...
Any clue ?
Quote from: TotO on 18:11, 08 July 13
I suggest you to use the M.E.S.S. FDC 765 emulation part, as it's more accurate than 90% of the existing CPC emulators and allow to run protected games as well.
Interesting. I'm going to take a look at this myself as my FDC implementation still feels a little ropey... :(
The FDC doesn't have a fifo.
It stores the data from the sector in it's data register 1 byte at a time.
The FDC remembers if the byte has been read by the CPU or not.
If the byte hasn't been read and it wants to put another byte into the data register this is the time it will give the overrun error condition.
So, as long as you read the data quickly, this condition doesn't happen and overrun error never comes.
When sector data is read, a byte comes every 32us.
Quote from: arnoldemu on 14:00, 23 July 13The FDC doesn't have a fifo.
It stores the data from the sector in it's data register 1 byte at a time.
The FDC remembers if the byte has been read by the CPU or not.
If the byte hasn't been read and it wants to put another byte into the data register this is the time it will give the overrun error condition.
So, as long as you read the data quickly, this condition doesn't happen and overrun error never comes.
When sector data is read, a byte comes every 32us.
That's were it's weird...
My understanding of the datasheet and all I read around is exactly what you're explaining. Even the 32us, which was the value I used for my FDC to tick (and eventually to overrun).
Anyway, with this game Chicago 90', I encounter overruns...
I think i'll have to disassemble a bit the code to understand where my timings are bad (which is the only solution i'm currently thinking of).
Quote from: arnoldemu on 14:00, 23 July 13
When sector data is read, a byte comes every 32us.
I thought it was 13us for MFM data and 26us for FM data. I could be wrong though as I've not actually measure it - my emulator just returns the next byte as soon as the CPU has consumed the previous one.
Quote from: ralferoo on 15:45, 23 July 13
I thought it was 13us for MFM data and 26us for FM data. I could be wrong though as I've not actually measure it - my emulator just returns the next byte as soon as the CPU has consumed the previous one.
I believe that these values are the response time to interrupt. In our case (no interrupt), these values have no meaning.
Quote from: Lone on 16:00, 23 July 13
I believe that these values are the response time to interrupt. In our case (no interrupt), these values have no meaning.
Well, except that the data rate of the encoded data on disk is 500,000 bits per second, which makes 250,000 bits per second after MFM decode, which is 31250 bytes per second, which is... oh 32us. Oh you guys were right all along! ;)
It depends on the master clock to the FDC. Those timings seem more for 8Mhz clock - and in fact a lot of the timings in the datasheet seem to imply an 8Mhz clock is being used. But on CPC and Spectrum it's 4Mhz.
MFM is more of a data format on the disc, FM is slightly different.
This is how I understand it in terms of PC disc formats:
High Density, MFM, 16us per byte.
Medium Density, MFM, 32us per byte.
Low Density, FM, 64us per byte.
Quote from: Lone on 16:00, 23 July 13
I believe that these values are the response time to interrupt. In our case (no interrupt), these values have no meaning.
Yes your probably correct. It probably means that when the cpu has received the interrupt it has those times before the next byte arrives. It probably takes into account a certain time for the interrupt to be acknowledged and the interrupt routine to be started.
I don't know where they came up with 13us and 26us myself, unless they are worse case, or for 360rpm discs. Perhaps they are the timings for 8" media and it's rotation speed?
Quote from: arnoldemu on 17:42, 23 July 13
Yes your probably correct. It probably means that when the cpu has received the interrupt it has those times before the next byte arrives. It probably takes into account a certain time for the interrupt to be acknowledged and the interrupt routine to be started.
I doubt it's the interrupt time, because you'd have the time of the gap between the IDAM and the DAM before the FDC would start giving you data, which is more likely be about 13 bytes, so about 400us.
Unless of course, the interrupt occurs when the sector data starts... I guess I'm gonna have to start measuring things! :O
Quote
I don't know where they came up with 13us and 26us myself, unless they are worse case, or for 360rpm discs. Perhaps they are the timings for 8" media and it's rotation speed?
They're definitely in the datasheet for the 765. That's where I read them at least.
I believe the fdc would trigger an interrupt for each data byte (if not using DMA mode) and then again when the result phase is ready.
If using DMA mode, it would trigger a DMA signal which would automatically cause the byte to be read and transferred (DACK??).
Of course, the fdc inside the cpc is run in non-DMA mode so those interrupts are triggered, but not connected on cpc. So we must read the status register to see what is happening. This explains why there is so much reference to interrupts and things like that in the fdc docs.
Terminal Count (TC) is another pin which is not used on CPC which is normally used on PC to interrupt data transfer - e.g. to read x bytes from a sector then trigger TC to tell FDC you're done.
So many features which are not used on CPC.
Quote from: ralferoo on 20:23, 23 July 13
Unless of course, the interrupt occurs when the sector data starts... I guess I'm gonna have to start measuring things! :OThey're definitely in the datasheet for the 765. That's where I read them at least.
Yes I read them there too.
The datasheet talks as if you are using a certain clock and certain setups.
Some of the timings I have measured to be longer with a 4Mhz clock - it does state this somewhere in the docs too.
When I investigate a bit further, I found out that my overrun problems are caused by interrupt not disabled during the protection routine reading :
Putting stop breakpoints inside it, I can see that, after some reading, an interrupt occur, then send me to 0038, which is a jump to B941... Which begin to read from the gate array... then my next byte is ready from the FDC, the previous one is not read, and overflow occurs.
Well well well....
So, I can think of two bugs in my code :
- Either I don't handle correctly interrupt, and it should be disabled. But when I use debg with WinAPE, it run as my code, with interrupt enabled.
- Overrun during a ReadTrack command don't stop the Execute phase to enter the Result phase (and data are still output, which can cause eventually the GAP data to be read). Anyway, a test with overrun being 'only' informative (on status 1 in Result phase) fails.
In fact, the only way to make it work, is to add this buffer fifo : I put a screen here (sorry, no cut/paste from disassembly available currently...)
[attach=2]
We see the code from 806A to 8088 : exactly &207 values are stored in 8089 (the last one being the one to check for the protection). Which means that if one or more bytes are missed (dur to overrun, due to interrupts), the last data written would be far more than the 207th one.
The sector data show us that there is 34 GAP data in this sector. For the protection to be ok, it means that the CPU can't miss more than 27 bytes, which is only 27*32 = 864 us in various interrupt.
512 data read from the disk is 512*32 = 16384 us, which means that not less than 16384 / 3328 = 4 interrupts occurs. Well, all of this seems to be a bit too random.
In fact, after all this, i take a look at the FDC from MESS, which seems to use an internal Fifo as well...
Any more clue ?
Quote from: Lone on 17:41, 24 July 13
We see the code from 806A to 8088 : exactly &207 values are stored in 8089 (the last one being the one to check for the protection). Which means that if one or more bytes are missed (dur to overrun, due to interrupts), the last data written would be far more than the 207th one.
That is the correct number of bytes for a single sector (512 from the execution phase and 7 from the result phase).
Quote
In fact, after all this, i take a look at the FDC from MESS, which seems to use an internal Fifo as well...
The 765 won't have a FIFO or it'd be documented in the manual (and also less critical to read it at the correct time). Modern PCs use the 82077 (or something similar) which is broadly compatible with the 765 but also includes a 16 byte FIFO.
Quote from: ralferoo on 18:33, 24 July 13
That is the correct number of bytes for a single sector (512 from the execution phase and 7 from the result phase).
The 765 won't have a FIFO or it'd be documented in the manual (and also less critical to read it at the correct time). Modern PCs use the 82077 (or something similar) which is broadly compatible with the 765 but also includes a 16 byte FIFO.
In fact, the protection used by this game is a GAP type protection.
That means there is a special track and sector. In Chicago90, it's track 39, sector 41.
This sector (which you can see here :
[size=78%]http://www.cpc-power.com/SectorData.php?fiche=548&slot=7&rang=0[/size]) contains special GAP data (the F7 you can see at the end).
The trick is to read with a "Read track" command, using a size of 3 (meaning 1024 bytes for a sector). After the 519th byte read, and copied to memory location 8089, the code stop reading incoming data (which cause a true overrun in this case).
All data that are after the 512 first bytes are not sector data, but CRC then GAP data.
Checking that the 7th byte after the sector real end is 7F and not the standard 4E value, is the protection.
Correct, read track reads past the end of the sector and reads the gap bytes.
correct, if it stops reading an overrun will be signalled.
The gap bytes are special here.
So to read this kind of protection you need to have very accurate fdc emulation and reproduce the raw mfm data exactly to get the perfect results.
Quote from: arnoldemu on 08:58, 25 July 13
Correct, read track reads past the end of the sector and reads the gap bytes.
correct, if it stops reading an overrun will be signalled.
The gap bytes are special here.
So to read this kind of protection you need to have very accurate fdc emulation and reproduce the raw mfm data exactly to get the perfect results.
In fact, it's exactly what I planned to do :
My paradigm is quite simple : When I read the dsk file, I rebuild the full disk structure, in a big buffer, including everything : GAP, CRC, Sync,etc.
My FDC "tick" every 32us. In this tick, if the motor is on, the head advance, and the next byte is then used.
During a read track command,I check if the previous byte has been read. If it's not the case, overrun is set. Otherwise, it is prepared to be available for the next IN command from the CPU.
With this method, most of the disk are read correctly, even this GAP protection. The problem I have is that overrun is always set, due to the CPU that didn't read on time the FDC data...
I'm checking my various counter right now, expecting an error that would cause my timings to be wrong.
.
After some testing :
It seems that there is, in fact, no buffer.
But the reading is not stopped by an overrun : Data continue to be outed until the end (with the bit overrun set).
I'll attach here a test, if someone can run it on a real CPC and post a result, it will help.
[attachurl=2]
Concerning the problem of Chicago90, there is in fact 34 byte in the GAP data, so it is possible to miss 33 bytes due to interrupt, and complete the test.
(512+7)*32 byte to read = 16608, which is about 5 interrupts (16608/3330 = 4.97...)
33*32 = 1056us, which should be enough to run few interrupts (200 us per interrupt in this case).
After being able to run this test program on a real CPC, I can finally have a conclusion on this particular point :
My test program do a Read Track of the sector C1 of track 1. It reads the 255 first bytes, then stop, and display the 20 first one on screen.
The second run do the same, but add a 60-70us delay between "data is ready" on main status register, and the effective read through the IO port.
Results are following :
Track data are :
00 54 46 44 43 20 20 20 20 42 49 4E 00 00 00 07 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 ......
Command is here : &42, &00, &00, &00, &C1, &02, &c1, &2a, &ff
First case reads 255 bytes, and display :
00 54 46 44 43 20 20 20 20 42 49 4E 00 00 00 07 02 00 00 00
Which is expected : It's exactly what's on the sector
Second case reads 156 bytes, and return :
46 20 20 4e 00 00 00 00 00 00 e5 e5 e5 e5....
Which is more or less one byte every three.
I think we can conclude that :
- FDC don't stop the read track command if an overrun is detected.
- FDC on the CPC had no buffer.
To relate this on Chicago 90 :
It seems that my previous assertion is right. Must be a timing problem on my code....
So let's return to investigations !
I wish to thanks to fano for the test run, by the way.
Right, the FDC765 has no buffer, a byte must be read every about 25 ys. It's all in the datasheet of the Floppy Buch ;-)
Last update and final point about Chicago 90.
After being able to test on a new dump, all works correctly.
It was the dump that wasn't correct (not enough GAP data : 34 is not enough...)
The correct number is 80 bytes, so far enough to run few interruptions during the process.
Thanks to Maxit for the correct dump.
Anyway, the datasheet was not clear (at least for me) about the fact that an overrun will not stop the data output.
Now, we have a proof !
.
There was an update beginning of December...
Sugarbox | Yet another CPC emulator... (http://sugarbox.free.fr/)
It's worth to follow this site up more often. :)
Thanks for mentioning it, TFM! Indeed it progresses nicely. I like this:
QuoteXBox controller can be used as joystick
But I'd like to see it making progress in the GUI front...
Fell free to mention every thing you want !
After all, today is christmas...
And I try to have a complete to-do list, with everything needed by everyone (in what I'm good for, which does not include nice icons, for example ).
I'm sure that for nice icons an such things (I can't do that either) you will find help here. We got some great graphics creators on the forum.
There are so many good icon resources out there it'd be pointless to really discuss it :D But anything would be better than a big 3D box with off-centre text.
Keep it up! :)
In general there are two philosophies: For some it is important how a program looks like, and for others it's important what a program can do. Personally I'm one of the latter category.
So - just IMHO - it's good to have a well emulator, the surface / interface can be improved later. What counts is what you got under the hood. But as stated - just IMHO.
Both are important, ever since 1988 or so. Of course functionality is more important, but once you get that, UI should be looked after. Especially when it's so easy.
Quote from: Gryzor on 20:05, 31 December 13
Both are important, ever since 1988 or so. Of course functionality is more important, but once you get that, UI should be looked after. Especially when it's so easy.
Good UI is not always easy.
True it's easy to put some buttons and labels and text boxes, but making it in a way that makes it natural to use is not so easy.
True that accurate emulation is very important.
Oh, don't get me wrong, I know that UI/UX is a whole science unto itself, and it takes a lot of thought to have an emulator have the features you want, where the user wants them. But yes, I was taking about the looks of it, a few properly sizes and aligned buttons and a handful of nice, self-explaining icons.
A new version is available... here : Sugarbox 0.15 is out. | Sugarbox (http://sugarbox.free.fr/?p=42)
Sorry for Gryzor, but no new sexy interface at this time. I promise I'll think about it for next release (don't forget that it's still in beta phase !)
Feel free to ask any question, or to report anything that goes wrong.
Here the log :
- CRTC detection tests are correctly passed (For CRTC 1 at least)
- Z80 : Lots of improvement in Interrupt and general timings
- Z80 : OUT write it's value with delay to the port (this make some demo works..)
- Z80 : When an interrupt is pending, EI / HALT works correctly (this make « L'arche du capitaine blood » original dump to work correctly)
- CRTC : Fix the adress computation : Only correct bits are compared. This correct the « The demo » demo.
- CRTC1 : Fix adjustement computation, when R5 > R9 (adjustement counter was only increased when VCC=R4)
- Gate Array : Corrected a bug in the MMR, that prevented Phortem demo to run
- Gate Array : IO handled at 4mhz to have precise timings for color changed- Ink changed should be pixel correct
- PPI8255 : CPC+ Feature of non-reset of Port ABC when writing control register implemented. This allow CRTC detection to be complete
- PPI8255 : Corrected a bug in PPI Control register, when bit7=0 (Shadow of the beast hanging bug in « press fire » screen is corrected)
- PPI8255 : Port B only readable.- FDC : Read Track correction, LATIS (Hercule2 – Translock) now ok
- FDC : Detection of end disk improved, even when GAP3 is wrong
- FDC : Disk with only MV – CPC now loads correctly- Monitor : Correction of a bug that prevented a detection of HBL in some case of the PLL ->Arkanoid I no longer crash the emulator
- Monitor : Rewrite the honrizontal synchronization mechanism.
- Monitor : Correction of HSync. CRTC R0=64 can be used now without hsync problems (The demo work better)
- Monitor : Improved handling of Hsync position via R2
- Monitor : Correct the garbage that occasionnaly appear on reset
- Monitor : Add handling of multiple HSync with correct synchronisation
- Reset is now fully implemented
- Settings : CRTC type is changed correctly
- Settings : Change does no longer reboot the CPC
Just checked it out! It works like a charm! And I like the interface: Found everything immediately. :)
Don't worry, functionality comes first :)
Well, I like it simple. If it get too complex my GPU overheats and I see colored clouds and can't do anything for a while. ;)
Hello there,
New version is available (0.16b) with some corrections, on the CRTC and FDC mainly.
It's now working with Windows XP, if Direct X is installed.
Testing it is a good way to discover the great job of all thoses demomakers !
Here it is : Sugarbox v0.16b | Sugarbox (http://sugarbox.free.fr/?p=50)
Great job, glad to see it's progressing!
Hi there,
New version available ! v0.17
Special feature are a better GUI, and a solution for the XInput XP problem : This version should run on windows XP, even without a correct XInput install.
Here's the link : Sugarbox v0.17b | Sugarbox (http://sugarbox.free.fr/?p=55&preview=true)
Here's the log :
- Gate array : MMR Corrected : If a 128k config is set, only 128k are available.
- Gate array : Corrected access to MMR and MMR through PAL
- Gate array : Mode 3 is handled
- Monitor : Change the function used for adjustement on HSync : Use a square root instead of a log, to make some demos more stable ("Camembert 4" demo for example)
- Timings : Adjust some timings for out command. "From scratch" demo now display correct colours at the correct place
- FDC : Reset is (really) fixed. It no longer set the FDC in a state that prevent it to be used
- FDC : Add delay during track change
- General : Load the Xinput lib in the code, to avoir non runing app on some XP systems.
- General : Screenshot option added
- General : Speed limit is more configurable, from 50% to no-limit
- General : Some code optimisations
- General : Screen size can change (from "full PAL display" to "standard CPC screen")
- General : Directories problems have been solved. It is now possible to drag'n'drop dsk file to a sugarbox shortcut (or to associate dsk with sugarbox)
- Sound : Volume slider added
- Sound : Mute option added
- Sound : Record is flushed, so the file is not only written at the end of the recording
- GUI : Current track number is displayed
- GUI : Add a "scanline" option
- GUI : Add nice icon for sound and disks
- GUI : Added Screenshot, settings and reset icons
- Startup : Associating "dsk" with sugarbox offer the possibilitty to load disk directly
WoW! That was a lot of work!!! Keep the project going! :) :) :)
Great steps with the GUI :)
Hello there,
New version is out.
SNA files are handled, and bug are fixed.
CRTC is a bit improved, and run almost all demos I can found.
By the way, if something is not working, drop me a line !
Here is the version :
Sugarbox v0.18 | Sugarbox (http://sugarbox.free.fr/?p=60)
Quote from: Lone on 21:48, 26 March 14
New version is out.
I enjoyed playing with this.
Would be nice to hear a bit about how you are finding the development of an emulator - such as: how did you write it, was it easier/harder than you thought and what's been the biggest challenge etc...?
Well...
In fact, writing an emulator was in my mind since I discover the first one, in the early '98, i believe. I didn't have enough time and competence, but I keep thinking about it since that day. Obvious target would be the CPC, as it's a "simple" computer, and, most of all, my first one when I was a child.
Since that day, I improved my coding skill through my work, and my experiments. Then, at the end of year 2012, I began to have a bit more time : My wife was pregnant, so she slept the whole evenings on the sofa, and all my current projects where finished, or at least I lost the motivation to continue them (I was running a really small blog on coding ).
So, I wrote the first lines, which was not that hard, as I was thinking of "how I would do if I want to" since about 14 years...
The whole process was not really difficult since that day, since LOTS of informations are available on the net (see the grimware, the cpcwiki and all data gathered by arnoldemu since that day).
Also, with twins at home, I have more time than I can afford to think, as giving 10 or 12 bottles a day (half of it incombed to me) let me think about it, at least when I was trying not to fall asleep.
Running basic was, at this time, easier than expected. Then come the two challenging parts I faced : Having an emulator that runs protected games, and all demos.
On these two parts, really few informations are available. Believe me or not, I became a real pro about googling particular subjects, to find the two sentences that can give me missing informations.
With a bit of support of really dedicated guys (Simon Owen, for example, send me couple of hints that were really precious about FDC support), I finally managed to make it run almost properly... But I still have lot's of question that didn't find an answer yet !
Speaking of the emulator itself, it's written in plain C++, plain Win32, Gdi. I added XLib for XBox controller support (as I wanted to play game with it), and added a debugger with lots of specific feature (like, breakpoint on CRTC register value).
I see it as experiment, so the code is not really nice, with lots of "Todo" mark, lots of things that should be rewritten, and so on... As I don't have enough time to do everything, I have to use priority to order what I would like to add and fix. Which is, basically, running on amstrad 6128 with CRTC 1, all the demos I find, and all protected softwares (and Futur OS, of course)
Then I will add CRTC 0, 2, 3, 4 support, second drive, CPC+ support, special hardware, etc...
I plan to add Direct X or other support when other parts will work correctly, as it's not necessary at this time (emulator running at 400% on my a bit modern i7 processor).
Sometime, also, I add GUI improvement, as it's fun to code (I had good time writing the sound slider for example), and make the emulator easier to use.
Also, I write on my todo list almost every comment made on it (not so many I can confess), which give me idea on what I can add.
I finally get a real CPC, but I'll have to fix the drive to use it (and believe it or not, finding this 5.25" drive cabble is not so easy by now...). I plan also to write specific tests, (on the CRTC of course !) to use the scientifi method on it : Hypothesis, experiments, conclusions. All these projects should keep me busy for the ten next years, I think !
Thank you for the insight, nice to hear about it.
I'd love to write an emulator one day and you're experience has reinforced this for me :)
I found about 90% of my answers through writing tests and running them on real machines.
I have a collection of tests for ay, 8255, keyboard, crtc, plus features, fdc.
But when I find information I do share it and document it.
Still there are some questions I haven't answered yet:
- exactly what state is the crtc type 3 and 4 in after reset; are all registers reset to 0 like on the others or something else?
There are a few more questions I need to answer.
I didn't release these tests yet because I wanted to make sure my emu passed them LOL.
Here is a new version, at least ! v0.19 is freshly compiled !
Lot's of effort on FDC support, with IPF, RAW, SCP and CT-RAW support (and a completely new paradigm).
Also some other features....
Here's the link : Sugarbox v0.19 | Sugarbox (http://sugarbox.free.fr/?p=90)
Really great work in the floppy section!!! :) :) :)
Your emulator runs Basun perfectly :) Awful game but nice disc protect... ehem bug xDDD, it stops the motor of the FDC, but try to read a sector and get datas before the motor get stopped completely.
A little version, that corrected some crashes on very few eDSK disk, and some double face SCP.
Also, corrected the vertical sync, and adjust the display zone a bit.
Here's the details :
Sugarbox v0.20 | Sugarbox (http://sugarbox.free.fr/?p=97)
Regards
Another version : Sugarbox v0.21 | Sugarbox (http://sugarbox.free.fr/?p=103)
Mainly remove the CAMPSImg.dll, that I shouldn't used that way for license reasons ( my bad, I *should* read all those boring stuff before using them !). Support for CT Raw and IPF is preserved as long as you get a proper DLL from the SPS Site.
Also, some few corrections in the CRTC (0 is supported !), some minor other corrections, and hopefuly no new bugs.
New version, once again.
Support for HFE, and various bug fix....
Sugarbox v0.22 | Sugarbox (http://sugarbox.free.fr/?p=113)
Great Work!!! :)
And thanks for adding to the package the FW314 and FW3.14EXP roms :)
Hello there
A quick note to inform you about a new release. It's 0.23 and here is what's new :
- [TAPE] : Tape support : CDT/WAV/VOC/CSW(v1.1 & v2.0, with or without Z-RLE encoding) files are supported
- [TAPE] : Possibility to save Tape as WAV, CDT (with only DRB or CSW blocks), CSW (v1.1 or 2.0 compressed). Preliminary, maybe unexpected results can occurs !
- [FDC] : Head is no longer forced to track 0 when a disk is ejcted. This fix a bug in disk swapping for Targhan.
- [FDC] : Track delay time added. This fixed a weird protection scheme on Daley Thompson Olymic Challenge
- [FDC] : The US1 FDC bit is no longer wired. This fixed "Sphaira" original game.
- [FDC] : When "Read id" is performed on a not formatted track, the track was incorrect in the result. This is now fixed, fixing "Return of the jedi".
- [FDC] : Fixed a bug that only load up to 42 tracks per side for a disk. Now, 720k disk (with 82 tracks) can be loaded again correctly
- [FDC] : Fixed a bug that prevent "motor" command to be taken in account
- [FDC] : Fixed a bug related to BC bit in register 2, making "Starfox" game to work.
- [GUI] : Added protection button for the disks
- [FDC-eDSK] : Correctly save tracks that are not formatted
- [FDC-DSK] : Close dsk file correctly.
- [SHORTCUTS] : added ctrl+f9 -> Reset
ctrl+f1 : insert disk drive A:
ctrl+f2 : insert disk drive B:
- [Gate array] : Fixed a bug that was displaying incorrect colors when using the ghost registers
- [General] : On exit, if a disk has been modified without being saved, user is asked about it.
- [General] : Fixed some rare crash that can occurs
- [General] : A click on speed on status bar now toggle the emulation speed between "100%" and "No speed limit"
- [General] : Some architecture and code optimization, increasing overall emulation speed (about +25% speed)
Here is the link : Sugarbox v0.23 | Sugarbox (http://sugarbox.free.fr/?p=117)
Thanks :)
Two small notes: at MAX size, borders are... awkward?
Also, it'd be nice if you implemented file associations for dsk images...
WoW! That's a MAJOR Update!!!! Awesome!!! :) :) :)
Yeah, sure it need an installer, but you can, by hand, associate dsk with it.
Or use command line. Or drag'n'drop !
The "max screen" feature is used to see the whole area (what is also not displayed). Maybe I should remove this, if it's to disturbing.
Don't forget we're still in beta phase, the beta tester are welcome to give their feeling about all of this !
Thanks anyway
Quote from: Lone on 23:14, 14 November 14
The "max screen" feature is used to see the whole area (what is also not displayed). Maybe I should remove this, if it's to disturbing.
No, please leave it. It's awesome for the development of Overscan-Games. Here an example: Please start "--RUN-ME" from this DSK under FutureOS. Press Space when you see the loading screen. Then Press "1" in the main menu. And in Game switch between "Normal" and "Max Screen". It makes a difference. Great to have the max screen option
I've tested the emulator today
it works very well, even CDT's (bleepload) that doesn't works on other emulators!!
Only that the CDT's i've tested, the sound of the tape is behind of the real data loaded in the emulator, with bleepload loader you will see the effect with the counter, or even in the standard blocks.
Other DSK that i've tested (weak sectors protected) load correctly here! (again other emulators dont'!)
Good Work!!
As I've written in another topic, I like this emulator a lot - especially since you informed me that fullscreen is on the "to do" list. :D
Is it just my sound card though, or does the sound emulation not render "noise" correctly? I'm not a sound expert, so this may be hard to describe, but normal music tones ("beep", "bloop") play correctly, but for example when you have a sound that's an explosion or a shot ("kccchhhh", "pssh") , it doesn't play. Does anyone else have this problem?
EDIT: I just looked up the words, sorry, English isn't my native language. The emulator seems to play tones just fine, but fails when it comes to producing noise.
Hey guys,
Thanks TheElectricMonk for your feedback. i'll try to investigate on this soon or later...
Also, I would like to present you a bit of beta version (a beta of a beta version, is this should be called a "Meta*beta" version ?)
Here's the point : I added some Full screen feature, but, I don't have too much material to test it in various condition, so I would apreciate if some of you could just run, test the full screen feature, and send me some feedback.
Here's the features :
- Windows mode : Add a special speed, called "VSync" : This just adjust the speed of emulation to your monitor. With this, the demo you run suffer no more tearing, stuttering, and are more fluid. Problem is that they are all a bit too fast : Monitor are ofter 60hz, then the whole CPC run at 120% of normal speed (with a bit of distorded sound, for example).
- Full screen is only supported through Direct X 9. VSync is also supported.
If you use the "100%" speed, it will test your monitor for a multiple of 50 hz frequency. You you're a lucky 100hz owner, then it will be fluid (like the vsync,but with correct speed !)
- Also, add a special menu item : "Insert blanck screen". With this, I tried to give a CPC monitor feeling (also for 100 hz owner), with insertion of a blanck screen between 2 normal frame. So you have a 50hz screen, which will destroy your eyes just like my old CPC monitor...
A tip : If you own a GSync monitor, disable GSync for "100%" speed with "Insert blanck screen" disabled (or you'll scync at an incorrect speed)/
Ans for 120-144hz monitor owner, turn it on with 100hz for best feeling.
All the advanced features need you to have a descent CPU ( a code I5 should be enough)
If you want to give me some feedback, please tell me :
- If it's work (or not), and which settings you have and use. This include :
- Windows version
- Direct X version
- GPU kind
- What you observe
- Speed of emulation, use of vsync/"Insert black frame"
- What did you tried to use
I also attached here a Snapshot of "Wake up" demo. First, because it's cool, and finally because I mainly use it to test the features.
The beta version of Sugarbox can be found here :
http://sugarbox.free.fr/release/Sugarbox_v0.24_b10.zip
EDIT : Save your work before running it !! It's my first project with DirectX, and it may be very unstable.... (didn't crash on the 3 machines I used, but... Never say never !)
Quote from: Lone on 15:40, 25 February 15
- Windows version: 7 - 64 bit
- Direct X version: 11
- GPU kind: NVIDIA GeForce 8700M GT
- What you observe: See below
- Speed of emulation, use of vsync/"Insert black frame": 100%
- What did you tried to use: Fullscreen
Great work!!!
In Fullscreen mode:
- The scanlines have different spacing, 8 are fine, 8 are to distanced. (Take a look at FutureOS desktop)
- I can't make a screenshot in fullscreen mode
Oh and you could rename the "Futur OS" configurations to "FutureOS". ;)
Anything else is pretty fine, it runs stable and well here. :) :) :)
A quick fix version is available here :
http://sugarbox.free.fr/release/Sugarbox_v0.24_b12.zip
This should correct the problem with full screen (no more crash, should work far better on some Virtualbox machine.
Also, the scanline problem have been corrected (by adapting the size of display to size of window, to avoid the problem seen on previous version.
I also corrected the FuturOS, but I juste found another typo with it (next release will have corrected). It's defined as the default os for this version, just because I tried the tribute to the sister with 100hz full screen, and... Well, it's a great full-screen-scroller !
Great motivation!!! Thanks!!! :) Currently I wait for somebody to paint me a fire wheel. Then I can move on to develop. :) :) :)
EDIT: Well, there is still some jerking in the game, but you won't see it in the menu. Just mention this as reference. Currently I overwork couple things, part is scrolling and its timing to enemy movement. Also playing Soundtrakker songs take up soooo much scanlines. Will nearly all get better in next WIP.
Hi! The latest release works well on my Laptop, but not on my Desktop (shows black screen only).
This version should fix it :
http://sugarbox.free.fr/release/Sugarbox_v0.24_b14b.zip (http://sugarbox.free.fr/release/Sugarbox_v0.24_b14b.zip)
Vsync crashes it on my laptop. GT640...
Hello there
A new beta version is now available. It's 0.24 and here is what's new :
- [FDC] : Read track handle correctly TC (Hercule, and ESAT software works again)
- [FDC] : Side changing is now correct : Game with only one side no longer crash if they try to access a second side (Dragon of flame)
- [FDC] : Fixed a bug if a sector CHRN is almost ok, when a read sector command is issued (Wild Street is now ok)
- [FDC] : FDC is more robust : Trying to load a random file as RAW will fail without a crash (hopefully)
- [TAPE] : RECORD function added
- [TAPE] : Added length of tape
- [TAPE] : Lot's of rework on the WAV support : Now load more files, including « Skate Crazy », « Basil », « Footballer of the year II » without the « reverse polarity » trick.
It mainly try to reproduce what's actually in the CPC : Filters, gains, and so on.
- [TAPE] : User can now set the Tape position at wanted position (by clicking on the counter status bar). Also, a shortcut is added to set tape to wanted block, or last ejection position
- [General] : Added file extension if needed, when saving file (for CDT, CSW, WAV, DSK, SCP, SNA files)
- [General] : Fixed a memory leak (which should have no impact on standard use)
- [Memory] : 464 has now no PAL
- [Display] : Full screen is now available for Direct X 9 display. Also, a smart sync has been added, to sync the display @50hz with 100hz display
- [DirectX9 display] : For people who want smooth display, it's possible to sync Sugarbox with your monitor. Display is smooth, but whole emulation speed is affected as well (typical 60 hz monitor will run at 120%)
- [DirectX9 display] : For lucky people with 100hz monitor, an option has been added, to insert a black frame between two frame. Whole speed is exactly 50hz, and display is really smooth.
* Hopefully * the various direct X crashes are fixed, but I have a limited testing setups (with not a single ATI card, believe it or not...)
Sugarbox v0.24 | Sugarbox (http://sugarbox.free.fr/?p=124)
Hey
New update of my emulator. I introduced SDL for the display (so easy lib to use...), so "fullscreen" has more options, like selecting resolution and refresh rate to use (which is fine if you own a 100hz capable monitor).
After some investigation of "how to realize smooth display", and interesting reading from Blur Busters | Everything Better Than 60Hz — including 120Hz, 144Hz, 240Hz, (http://www.blurbusters.com) I worked on the "black frame insertion", to produce smooth 50hz display.
Also added a direct dsk/tape and snapshot handling from CPC-Power and amstrad.eu online libraries.
Also, lot's of various fix are included
Sugarbox v0.25 | Sugarbox (http://sugarbox.free.fr/?p=133)
Here is the complete log :
- [General] : Optimisations (Emulation is about 15% faster)
- [General] : Generic Joystick are supported through Direct Input. 2 Joysticks can be used, in the order they appear in the os. Work with Xbox controler, as well as standard usb joystick.
- [SNR] : Add feature to watch SNR file (playbacks) – Preliminary
- [Z80] : Fixed timing issue in interrupt following some opcodes
- [Z80] : Fixed incorrect R increment for DD CB and FD CB instructions
- [FDC] : Fixed « Format » command. Now, a Format command from discology (for example) produce a disk that is correct.
- [FDC] : Fixed the MSR, that was not handled correctly. This fix Bobby bearing and Camelot warriors original dsk.
- [FDC] : Fixed the Step Rate Time computation, which was twice longe than expected
- [FDC] : Fixed behaviour with SK bit and deleted sectors (making Nigel Mansell works)
- [FDC] : Fixed how read track over the index hole works. The current sector is finished,then the command is ended (fix Skyx)
- [eDSK] : Fixed an incorrect behaviour with non formatted tracks on some dump. This prevents Bobby Bearing (UK) (1986) (CPM) [Original].dsk to crash when trying to load
- [eDSK] : Fixed some rare problematic case with offset-info datas
- [CT-Raw] : Fixed write bug when multiple revolutions exists (which somewhere shifted what's written, leading to CRC error). Fix « Le maitre absolu » in ct-raw format
- [Memory] : Fixed a bug in the PAL, preventing SymbOs to use full memory.
- [GUI] : Fixed missing space and enter for Autotype
- [GUI] : Added a PAUSE feature, accessible via menu or the « Pause » key on the keyboard
- [Z80] : Fixed a rare bug that can lead to potential unwanted deadlock with HALT command
- [TAPE] : FAST loading enabled : If a tape is read, refresh are cut, so speed can be 2 to 3 time faster.
- [Display] : SDL2 lib is now used. Fullscreen option is now better, as it can be fully configured. Also, black screen insertion for 100hz display can be used for buttery smooth scrollers
- [Display] : Screen size and position is now more correct
- [Display] : Screenshots are now better (and without any toolbar)
- [Printer] : A really basic printer is now plugged ! You can see print result in the PRINT directory. (no graphical printing is done, only text)
- [Online libraries] : Preliminary integration of CPC-Power and Amstrad.eu online libraries.
Hi Lone!
Great comprehensive update. Please also update the onboard FutureOS. I got used to use hotkey, now I really miss 'em if I have to use the mouse arrow. ;D :) :)
Quite a changelog! Downloading... :)
Stupid Avast thinks it's an virus, told em not, but :picard2: