f



Just got a really stupid idea.

It's not the first time I've had this stupid idea, but maybe it's the 
first time I can do something with it.

See, I'm thinking of writing another CP/M emulator, in the vein of myz80, 
so it would be running actual CP/M and I'd probably need to develop the 
emulated BIOS...

This is where I'd be in over my head.  I've started to pick up Z80 (I have 
a Windows version of "zmac" that I've been using to port Nascom Basic to 
the Apple ][ as a proof of concept), and my return to experimenting with 
the programs I used 15 years ago (myz80 and the Jim Lopushinsky emulators) 
got me thinking that maybe where I failed then, trying to create a virtual 
CP/M computer in C, I might be able to pull it off now.

Basically, I'm talking about almost literally *building a computer* in 
software, as if it were pieces of hardware being assembled on breadboard - 
the same way I have written most of my existing emulators.

-uso.
0
Steve
10/27/2016 5:13:27 AM
comp.os.cpm 3422 articles. 0 followers. Post Follow

28 Replies
433 Views

Similar Articles

[PageSpeed] 41

On 10/26/16 10:13 PM, Steve Nickolas wrote:

> Basically, I'm talking about almost literally *building a computer* in software, as if it were pieces of hardware being
> assembled on breadboard

that is the way MAME works internally


0
Al
10/27/2016 2:12:20 PM
On Thursday, October 27, 2016 at 4:11:52 PM UTC+2, Al Kossow wrote:
> On 10/26/16 10:13 PM, Steve Nickolas wrote:
> 
> > Basically, I'm talking about almost literally *building a computer* in software, as if it were pieces of hardware being
> > assembled on breadboard
> 
> that is the way MAME works internally

Same with z80pack. The included system emulations are build from
components, and the components can be combined to build other system,
and new components can be added too of course.
0
Udo
10/27/2016 4:24:43 PM
On Thu, 27 Oct 2016, Udo Munk wrote:

> On Thursday, October 27, 2016 at 4:11:52 PM UTC+2, Al Kossow wrote:
>> On 10/26/16 10:13 PM, Steve Nickolas wrote:
>>
>>> Basically, I'm talking about almost literally *building a computer* in software, as if it were pieces of hardware being
>>> assembled on breadboard
>>
>> that is the way MAME works internally
>
> Same with z80pack. The included system emulations are build from
> components, and the components can be combined to build other system,
> and new components can be added too of course.
>

I thought it was usually just kitbashed to kindasorta work like the real 
thing (the way I've usually written my emulators) and MAME/MESS was an 
exception.

But at any rate I came up with something crude, lacking any sort of drive 
hardware, but with a quasi-VT52 terminal, and a Z80 with 64K RAM and 8K 
ROM that can be shut off, which I figure is probably more than sufficient.
The terminal runs at a somewhat low 480x200 resolution, to allow for some 
UI to be slapped on the side of a CGA display (it was the easiest way to 
get some stuff up very quickly).

I guess the next step is to figure out a way to *realistically* (without 
shortcuts) emulate a disk drive interface.

-uso.
0
Steve
10/27/2016 8:58:31 PM
On Thursday, October 27, 2016 at 10:58:32 PM UTC+2, Steve Nickolas wrote:

> I guess the next step is to figure out a way to *realistically* (without 
> shortcuts) emulate a disk drive interface.

Cromemco 16FDC is great fun to emulate, because if it is not very accurate system software
won't run. No shortcuts with that one ;-)
0
Udo
10/27/2016 9:21:25 PM
On Thursday, October 27, 2016 at 10:58:32 PM UTC+2, Steve Nickolas wrote:
> On Thu, 27 Oct 2016, Udo Munk wrote:

> > Same with z80pack. The included system emulations are build from
> > components, and the components can be combined to build other system,
> > and new components can be added too of course.

Nope, z80pack always had that design because originally it came from
industrial controller development stuff.

In the current version you can select:

Mainframe: Altair, Imsai, Z-1
CPU: Z80, 8080
Memory: 64K + some sort of banking
SIO: my own, MITS, IMSAI, Cromemco
PIO: my own, MITS, IMSAI, Cromemco
FDC: my own, Tarbell, IMSAI, Cromemco
Display: ANSI/VT-100, Dazzler graphics

The included machine emulations are historically correct, but you can combine
all components as you like. E.g. take the Altair Mainframe, use a FDC from Cromemco
and a SIO from IMSAI, whatever.
0
Udo
10/27/2016 9:50:26 PM
On Thu, 27 Oct 2016, Udo Munk wrote:

> On Thursday, October 27, 2016 at 10:58:32 PM UTC+2, Steve Nickolas wrote:
>
>> I guess the next step is to figure out a way to *realistically* (without
>> shortcuts) emulate a disk drive interface.
>
> Cromemco 16FDC is great fun to emulate, because if it is not very accurate system software
> won't run. No shortcuts with that one ;-)
>

Oh geez.

Then again, I think the same is true of Apple's "disk ][" to some 
extent... I dunno how picky CP/M is but ProDOS is very strict about the 
drive hardware working exactly right.

-uso.
0
Steve
10/27/2016 9:51:42 PM
On Thursday, October 27, 2016 at 11:51:43 PM UTC+2, Steve Nickolas wrote:
> On Thu, 27 Oct 2016, Udo Munk wrote:
 
> Oh geez.
> 
> Then again, I think the same is true of Apple's "disk ][" to some 
> extent... I dunno how picky CP/M is but ProDOS is very strict about the 
> drive hardware working exactly right.

Yep. CP/M is not picky, but some DOS disks had nasty but of course not working
"copy protections", so it needs to support nibble access and who knows what.
Virtual ][ is very good with that, but no sources available, so no idea how it looks
like inside.
0
Udo
10/27/2016 10:02:12 PM
On Thu, 27 Oct 2016, Udo Munk wrote:

> On Thursday, October 27, 2016 at 11:51:43 PM UTC+2, Steve Nickolas wrote:
>> On Thu, 27 Oct 2016, Udo Munk wrote:
>
>> Oh geez.
>>
>> Then again, I think the same is true of Apple's "disk ][" to some
>> extent... I dunno how picky CP/M is but ProDOS is very strict about the
>> drive hardware working exactly right.
>
> Yep. CP/M is not picky, but some DOS disks had nasty but of course not working
> "copy protections", so it needs to support nibble access and who knows what.
> Virtual ][ is very good with that, but no sources available, so no idea how it looks
> like inside.
>

Yeah... I've dealt with a number of disks where I would have liked to try 
cracking them but AppleWin's disk emulation isn't precise enough for weird 
stuff like Spiradisc... :/

And MAME claims to support EDD images but apparently it's not accurate 
enough yet, because it goes down in flames on some of them...

-uso.
0
Steve
10/27/2016 10:36:11 PM
Anyway, I got a simple setup with a port of Nascom Basic so I can try out 
the terminal stuff. (I have a screenshot on Twitter.)

The next and most important part is going to have to be cut in 3 pieces 
and is the tricky one.

I have never successfully emulated, on my own, any sort of floppy 
controller, and I'd like to be able to design this system around some sort 
of realistic configuration. (I think that apart from the terminal port 
being a bit oversimplified - and to be fair, I think it's a realistic 
enough design even so to have a built-in terminal as basically its own 
computer - isn't that basically how some of DEC's 8 and 16-bit stuff 
worked? - the design so far is reasonably realistic.)  I guess the 
bootloader will want to load up a single sector at either the top of RAM, 
or just above ROM, where it will flip off the ROM with an OUT instruction, 
then continue to load CP/M...  That would be the first next stage. (I 
could just say "oh, punch a sector number and an address into a port", but 
that feels like cheating.)

After that, once I can read stuff off a virtual floppy, the next step 
would be CP/M 2.2.

Finally, CP/M 3.1.

-uso.
0
Steve
10/28/2016 2:05:00 AM
Udo wrote:
> Display: ANSI/VT-100, Dazzler graphics

Have you considered adding the Miniterm Associates' MERLIN graphics card as a display option?

I liked Cromemco products, but I chose the MERLIN over the DAZZLER for my S-100 system back in 1978. The Dazzler was color-flashy but the pixel resolution and text modes were not great.

A MERLIN with the Super-Dense option (i.e. daughter card) it have 320x200 pixel graphics / text. The monitor ROMs were very nice with documented entry points so it was easy to write ASM code that used the display fully. The later graphics basic was very nice too. I bought a Paper Tiger printer with the graphics option for it... nice combination.

The only thing I didn't like about the MERLIN was the significant radio frequency interference it generated. I considered redoing the board layout a few times over the years but couldn't justify the time.

I've got all my systems and documentation; if you're interested I could scan the MERLIN sales brochure or probably reference a BYTE or KILOBAUD article about it.

JDallas
0
10/28/2016 2:11:11 AM
On Friday, October 28, 2016 at 4:05:02 AM UTC+2, Steve Nickolas wrote:

> I have never successfully emulated, on my own, any sort of floppy 
> controller, and I'd like to be able to design this system around some sort 
> of realistic configuration. (I think that apart from the terminal port 
> being a bit oversimplified - and to be fair, I think it's a realistic 
> enough design even so to have a built-in terminal as basically its own 
> computer - isn't that basically how some of DEC's 8 and 16-bit stuff 
> worked? - the design so far is reasonably realistic.)  I guess the 
> bootloader will want to load up a single sector at either the top of RAM, 
> or just above ROM, where it will flip off the ROM with an OUT instruction, 
> then continue to load CP/M...  That would be the first next stage. (I 
> could just say "oh, punch a sector number and an address into a port", but 
> that feels like cheating.)

But that is how a FDC works, you step the motor to some track
and then tell it to read/write a sector to/from some address.
Even John Torode's FDC worked like that as one can see in the
1975 CP/M sources, and he had no large scale silicon from WD
or anyone. He had to build the state engine with discrete logic, same
as MITS and IMSAI.

The only possible cheat is to ignore all the nasty timing details,
which I have done, because I see no reason to wait 50ms for a head
load, or 10ms for stepping to the next track. With the physically
moving parts it is inevitable, because one cannot move a mass > 0
in no time, but in emulations we have no moving parts and so we
can speed up this things a bit. Of course one could implement the
timing correct and make users waiting for nothing, some emulations
do this.


0
Udo
10/28/2016 9:15:52 AM
On Friday, October 28, 2016 at 4:11:06 AM UTC+2, Jay_in_Dallas wrote:

> Have you considered adding the Miniterm Associates' MERLIN graphics
> card as a display option?

No, I don't know anything about it.

> I've got all my systems and documentation; if you're interested
> I could scan the MERLIN sales brochure or probably reference a
> BYTE or KILOBAUD article about it.

For building an emulation one needs complete manuals that describe
the functionality in detail. For testing such an emulation one
needs existing software, that runs unaltered and produces the same
result as the hardware.
0
Udo
10/28/2016 9:51:00 AM
JDallas wrote:
> Have you considered adding the Miniterm Associates' MERLIN...
> ...I've got all my systems and documentation; if you're interested
> I could scan the MERLIN sales brochure or probably reference a
> BYTE or KILOBAUD article about it...

Udo wrote:
> ...For building an emulation one needs complete
> manuals that describe the functionality in detail.
> For testing such an emulation one needs existing
> software, that runs unaltered and produces the
> same result as the hardware...

Of course.

But *first* you must decide if its something you want to pursue or not, which is why I recommended only a sales brochure or magazine article initially.

Should you proceed, I have all my boards, manuals, roms, and rom listings (in the manual). However, the manual never updated their blank "Theory of Operation" section, or if they did, I never got the update; doubtful because I was actively getting them until they closed. That section was just to describe the way the board worked, which was like most display boards on the 70s, a massive shift register and logic glue.

The manuals were otherwise quite detailed. I've seen a set online in PDF format so you could use that if you drill-down for more information before making a decision. I'll look for that URL if you pursue the MERLIN any further.

The Graphics BASIC (if I recall, written by David King who wrote the monitor roms) does not include source files. I probably have that on an era-NorthStar floppy, but that wouldn't be immediately accessible/available.

I think I saw the sales brochure posted online at one of the archive sites. If I find that, I'll post a URL if needed.

By default, I'll assume you're not interested in pursuing it, if you drop the MERLIN topic at this point. It could be a lot of work for a small niche or it could be a fairly capable graphics/text display to add to your software package. That's your decision.

JDallas
0
10/28/2016 2:41:07 PM
On Friday, October 28, 2016 at 4:41:01 PM UTC+2, Jay_in_Dallas wrote:

> By default, I'll assume you're not interested in pursuing it, if
> you drop the MERLIN topic at this point. It could be a lot of work
> for a small niche or it could be a fairly capable graphics/text
> display to add to your software package. That's your decision.

Not right now, because my todo list already is long enough for years
of work. Also emulation of S100 or ECB video boards from that periode
can be added by anyone with to much time on their hands. Development
is independend from what I'm doing and the Dazzler implementation can
be used as a reference, how to do that.
0
Udo
10/28/2016 4:11:58 PM
> The only possible cheat is to ignore all the nasty timing details,
> which I have done, because I see no reason to wait 50ms for a head
> load

Normally that is correct, however, with some FDC software you find
delay loops which are designed to make the CPU wait as long as it
takes till the FDC hardware has done its thing. So the emulated FDC has
to do likewise. Usually there is enough slack in the system that you
don't have to be 'spot on' and you can vary both the
emulated-hardware and the emulated CPU delays quite a bit without
them getting out of sync.

It helps to use a state-machine for the emulated FDC hardware.

Jack
-- 
"It's rather cold." she said bitchily.

0
Jack
10/29/2016 4:35:03 AM
On Saturday, October 29, 2016 at 11:48:07 AM UTC+2, Jack Strangio wrote:
> > The only possible cheat is to ignore all the nasty timing details,
> > which I have done, because I see no reason to wait 50ms for a head
> > load
> 
> Normally that is correct, however, with some FDC software you find
> delay loops which are designed to make the CPU wait as long as it
> takes till the FDC hardware has done its thing. So the emulated FDC has
> to do likewise. Usually there is enough slack in the system that you
> don't have to be 'spot on' and you can vary both the
> emulated-hardware and the emulated CPU delays quite a bit without
> them getting out of sync.

In most cases the software just waits for some state, but doesn't measure the
time it needs. So if a driver switches the motor on, it doesn't matter if the
motor is signalled ready immediately, or after 2 seconds a physical motor needs to
spin up, you just need to set the flag bit in the controller saying that it is ready.
Not so with some of the Cromemco software, they even measure the rotational
speed of the disk and so on. So an emulation for these devices needs to be
very accurate.

> It helps to use a state-machine for the emulated FDC hardware.

Definitely, also the silicon FDC's are state machines implemented with
logic.
0
Udo
10/29/2016 1:08:54 PM
On 27/10/2016 23:50, Udo Munk wrote:
> On Thursday, October 27, 2016 at 10:58:32 PM UTC+2, Steve Nickolas wrote:
>> On Thu, 27 Oct 2016, Udo Munk wrote:
>
>>> Same with z80pack. The included system emulations are build from
>>> components, and the components can be combined to build other system,
>>> and new components can be added too of course.
>
> Nope, z80pack always had that design because originally it came from
> industrial controller development stuff.
>
> In the current version you can select:
>
> Mainframe: Altair, Imsai, Z-1
> CPU: Z80, 8080
> Memory: 64K + some sort of banking
> SIO: my own, MITS, IMSAI, Cromemco
> PIO: my own, MITS, IMSAI, Cromemco
> FDC: my own, Tarbell, IMSAI, Cromemco
> Display: ANSI/VT-100, Dazzler graphics
>
> The included machine emulations are historically correct, but you can combine
> all components as you like. E.g. take the Altair Mainframe, use a FDC from Cromemco
> and a SIO from IMSAI, whatever.

I can suggest as next step, a 256 byte granularity in selecting memory 
size, so one can emulate the very first, 1975, altairs (256 byte RAM, we 
have already the toggable control panel...) ? ;)

OTOH, I know for sure that 4K basic don't actually need 4K of RAM, IIRC 
work with SIN/TAN/RND with only ~ 3,75 Kb RAM, albeit with really tiny 
space for BASIC programs, but the test was done simply declaring 
decreasing available ram at the HOW MANY RAM prompt, so I'm not really 
100% sure until I can have an actual emulation with 3 3/4 Kb RAM.

Best regards from Italy,
dott. Piergiorgio.



0
dott
10/30/2016 1:49:30 PM
On Thursday, October 27, 2016 at 1:13:28 AM UTC-4, Steve Nickolas wrote:
> It's not the first time I've had this stupid idea, but maybe it's the=20
> first time I can do something with it.
>=20
> See, I'm thinking of writing another CP/M emulator, in the vein of myz80,=
=20
> so it would be running actual CP/M and I'd probably need to develop the=
=20
> emulated BIOS...
>=20
> This is where I'd be in over my head.  I've started to pick up Z80 (I hav=
e=20
> a Windows version of "zmac" that I've been using to port Nascom Basic to=
=20
> the Apple ][ as a proof of concept), and my return to experimenting with=
=20
> the programs I used 15 years ago (myz80 and the Jim Lopushinsky emulators=
)=20
> got me thinking that maybe where I failed then, trying to create a virtua=
l=20
> CP/M computer in C, I might be able to pull it off now.
>=20
> Basically, I'm talking about almost literally *building a computer* in=20
> software, as if it were pieces of hardware being assembled on breadboard =
-=20
> the same way I have written most of my existing emulators.
>=20
> -uso.

It is a stupid idea. (No; not really.) I say that because I had the same st=
upid idea - where are we? October? - about two months ago. I did just that:=
 a full computer totally in software. I spent much more time adding feature=
s to the emulator than I did developing the engine (he says with shame). I =
targeted the 8080 bc. it was easy and efficient to emulate its instruction =
set. (I have plans to add Z80 support but I'm not yet mentally ready to dea=
l with its four-byte instructions.)

My system is truly generic; it simulates no particular system or OS. All bi=
ts 'n pieces are configurable and pulled together by a config file. (Elemen=
ts can also be dynamically added/removed at runtime.) For example, if you w=
ant memory banking, you have to add a HW "driver," map it into memory or IO=
 address space, and define your communications protocol, i.e. write 0Ah to =
port 22h to blah, blah, blah ...=20

At this point, I have a 4-drive FDC, an RTC, console, SIO, PIO, tape reader=
/writer (just derivatives of the SIO), and printer (also an SIO derivative)=
.. The disk system is generic enough that it can handle *anything* (as long =
as I know/can discover the disk geometry). I had no intention of simulating=
 anything so everything runs at "full speed." I do have a "throttle" featur=
e that can add an arbitrary delay between every instruction fetch/decode bu=
t I make no use of it. I easily have sub-millisecond performance so I'm hap=
py. I chose CP/M 2.2 as my first OS to drop into it. I changed one byte in =
the DRI sources, wrote a BIOS, a boot loader, and a boot ROM. Thrilling to =
see "a>'

I have a few more things to double-check before I label it done. Oh ... and=
 the user manual needs to be written. Oh ... and I have to pull together my=
 development notes.
0
Liam
10/30/2016 8:16:08 PM
On Thursday, October 27, 2016 at 1:13:28 AM UTC-4, Steve Nickolas wrote:
> It's not the first time I've had this stupid idea, but maybe it's the=20
> first time I can do something with it.
>=20
> See, I'm thinking of writing another CP/M emulator, in the vein of myz80,=
=20
> so it would be running actual CP/M and I'd probably need to develop the=
=20
> emulated BIOS...
>=20
> This is where I'd be in over my head.  I've started to pick up Z80 (I hav=
e=20
> a Windows version of "zmac" that I've been using to port Nascom Basic to=
=20
> the Apple ][ as a proof of concept), and my return to experimenting with=
=20
> the programs I used 15 years ago (myz80 and the Jim Lopushinsky emulators=
)=20
> got me thinking that maybe where I failed then, trying to create a virtua=
l=20
> CP/M computer in C, I might be able to pull it off now.
>=20
> Basically, I'm talking about almost literally *building a computer* in=20
> software, as if it were pieces of hardware being assembled on breadboard =
-=20
> the same way I have written most of my existing emulators.
>=20
> -uso.

It is a stupid idea. (No; not really.) I say that because I had the same st=
upid idea - where are we? October? - about two months ago. I did just that:=
 a full computer totally in software. I spent much more time adding feature=
s to the emulator than I did developing the engine (he says with shame). I =
targeted the 8080 bc. it was easy and efficient to emulate its instruction =
set. (I have plans to add Z80 support but I'm not yet mentally ready to dea=
l with its four-byte instructions.)=20

My system is truly generic; it simulates no particular system or OS. All bi=
ts 'n pieces are configurable and pulled together by a config file. (Elemen=
ts can also be dynamically added/removed at runtime.) For example, if you w=
ant memory banking, you have to add a HW "driver," map it into memory or IO=
 address space, and define your communications protocol, i.e. write 0Ah to =
port 22h to blah, blah, blah ...=20

At this point, I have a 4-drive FDC, an RTC, console, SIO, PIO, tape reader=
/writer (just derivatives of the SIO), and printer (also an SIO derivative)=
.. The disk system is generic enough that it can handle *anything* (as long =
as I know/can discover the disk geometry). I had no intention of simulating=
 anything so everything runs at "full speed." I do have a "throttle" featur=
e that can add an arbitrary delay between every instruction fetch/decode bu=
t I make no use of it. I easily have sub-millisecond performance so I'm hap=
py. I chose CP/M 2.2 as my first OS to drop into it. I changed one byte in =
the DRI sources, wrote a BIOS, a boot loader, and a boot ROM. It was really=
 quite thrilling to see "a>' for the first time.

I have a few more things to double-check before I label it done. Oh ... and=
 the user manual needs to be written. Oh ... and I have to pull together my=
 development notes.

I wish you much fun and success pulling together your emulator! Make sure y=
ou're sitting down when you fire it up with its first OS.
0
Liam
10/30/2016 8:19:25 PM
On Sunday, October 30, 2016 at 2:49:31 PM UTC+1, dott.Piergiorgio wrote:

> I can suggest as next step, a 256 byte granularity in selecting memory 
> size, so one can emulate the very first, 1975, altairs (256 byte RAM, we 
> have already the toggable control panel...) ? ;)

The features for 1.29 are set, after that the memory management will
be improved further.

> OTOH, I know for sure that 4K basic don't actually need 4K of RAM, IIRC 
> work with SIN/TAN/RND with only ~ 3,75 Kb RAM, albeit with really tiny 
> space for BASIC programs, but the test was done simply declaring 
> decreasing available ram at the HOW MANY RAM prompt, so I'm not really 
> 100% sure until I can have an actual emulation with 3 3/4 Kb RAM.

You can look at memory >4K if anything gets changed, or add an trap into
the emulation for memory write >= 4096.
0
Udo
10/30/2016 8:23:47 PM
On Sun, 30 Oct 2016, Liam Fry wrote:

> On Thursday, October 27, 2016 at 1:13:28 AM UTC-4, Steve Nickolas wrote:
>> It's not the first time I've had this stupid idea, but maybe it's the
>> first time I can do something with it.
>>
>> See, I'm thinking of writing another CP/M emulator, in the vein of myz80,
>> so it would be running actual CP/M and I'd probably need to develop the
>> emulated BIOS...
>>
>> This is where I'd be in over my head.  I've started to pick up Z80 (I have
>> a Windows version of "zmac" that I've been using to port Nascom Basic to
>> the Apple ][ as a proof of concept), and my return to experimenting with
>> the programs I used 15 years ago (myz80 and the Jim Lopushinsky emulators)
>> got me thinking that maybe where I failed then, trying to create a virtual
>> CP/M computer in C, I might be able to pull it off now.
>>
>> Basically, I'm talking about almost literally *building a computer* in
>> software, as if it were pieces of hardware being assembled on breadboard -
>> the same way I have written most of my existing emulators.
>>
>> -uso.
>
> It is a stupid idea. (No; not really.) I say that because I had the same 
> stupid idea - where are we? October? - about two months ago. I did just 
> that: a full computer totally in software. I spent much more time adding 
> features to the emulator than I did developing the engine (he says with 
> shame). I targeted the 8080 bc. it was easy and efficient to emulate its 
> instruction set. (I have plans to add Z80 support but I'm not yet 
> mentally ready to deal with its four-byte instructions.)

I've never dared to write my own CPU cores.

I have been working on an Apple ][ emulator that uses an extremely modular 
approach (almost EVERYTHING is farmed out to DLLs) and I could probably do 
that here too.

-uso.
0
Steve
10/30/2016 9:55:18 PM
Udo wrote:
> ..The only possible cheat is to ignore all the nasty
> timing details, which I have done, because I see
> no reason to wait 50ms for a head load, or 10ms
> for stepping to the next track...

If you want to simulate events in virtual-time, you can set up a simulation kernel using a current time variable and a priority queue structure to maintain the next chronological event. This allows you to simulate various event threads in chronologically-parallel task sequences. This is much easier than trying to juggle many events and plan out processing order.

Each event in the priority queue has (1) an event activation time value used to automatically sort events in the queue, (2) a link to where that event task is processed and (3) a reference to the event's associated object so that the correct ram variables are used by the processing (if you have two floppies, their simulation variables can't be mixed up, but the same code can run both).

You could accurately simulate the position spin of a floppy disk under a read-write head while other independent events are also being properly processed in order.

A good, advanced textbook on simulations is "Simulation Modeling & Analysis" by Law & Kelton.

You can find *priority queues* in any computer science, data structures textbook. Its a useful construct that belongs in any coder's bag-of-tricks.

JDallas
0
10/31/2016 8:42:06 PM
On Saturday, October 29, 2016 at 8:08:59 AM UTC-5, Udo Munk wrote:
> On Saturday, October 29, 2016 at 11:48:07 AM UTC+2, Jack Strangio wrote:
> > > The only possible cheat is to ignore all the nasty timing details,
> > > which I have done, because I see no reason to wait 50ms for a head
> > > load
> >=20
> > Normally that is correct, however, with some FDC software you find
> > delay loops which are designed to make the CPU wait as long as it
> > takes till the FDC hardware has done its thing. So the emulated FDC has
> > to do likewise. Usually there is enough slack in the system that you
> > don't have to be 'spot on' and you can vary both the
> > emulated-hardware and the emulated CPU delays quite a bit without
> > them getting out of sync.
>=20
> In most cases the software just waits for some state, but doesn't measure=
 the
> time it needs. So if a driver switches the motor on, it doesn't matter if=
 the
> motor is signalled ready immediately, or after 2 seconds a physical motor=
 needs to
> spin up, you just need to set the flag bit in the controller saying that =
it is ready.
> Not so with some of the Cromemco software, they even measure the rotation=
al
> speed of the disk and so on. So an emulation for these devices needs to b=
e
> very accurate.
>=20

Sounds similar to some of the Heathkit hard-sectored floppy issues I had to=
 handle in my emulator. There was no controller chip on the board, just an =
AMI S2350 USRT, which handled to parallel -> serial and serial -> parallel =
conversion between the CPU and the floppy disk. I was thinking, I would mak=
e it run faster, by always returning the next byte on the disk image, even =
if it wouldn't have been ready on a real system. Although that allowed the =
system to read a given sector faster, the software expected to see the next=
 sector within a certain about of time, but since it had read the sector to=
o fast, it didn't find the next one within the time limit. So it would then=
 flag a soft-error and then have to re-enter the sector find process. Lucki=
ly, there was a software testing program that fully exercised the drive sys=
tem. During a run there would be hundreds of soft-errors. Once I change eac=
h read data byte to be clock cycle accurate, the number of soft-errors went=
 down to zero.
If anyone is interested in the Heathkit H89 emulator, you can find it on gi=
thub:  https://github.com/mgarlanger/VirtualH89 =20
The Z80 emulation started with Udo's excellent z80pack software, which I co=
nverted to C++ to fit with the rest of the design.

0
Mark
11/4/2016 4:24:12 AM
On Friday, November 4, 2016 at 5:24:13 AM UTC+1, Mark Garlanger wrote:

> If anyone is interested in the Heathkit H89 emulator, you can find
> it on github:  https://github.com/mgarlanger/VirtualH89  
> The Z80 emulation started with Udo's excellent z80pack software,
> which I converted to C++ to fit with the rest of the design.

I looked a bit through some of the sources, really nice work, great
to see what others can do with it.

It would help if you could add some informations where to get the
Heath ROM's and OS disk images.
0
Udo
11/4/2016 11:17:38 AM
On Friday, November 4, 2016 at 6:17:39 AM UTC-5, Udo Munk wrote:
> On Friday, November 4, 2016 at 5:24:13 AM UTC+1, Mark Garlanger wrote:
> 
> > If anyone is interested in the Heathkit H89 emulator, you can find
> > it on github:  https://github.com/mgarlanger/VirtualH89  
> > The Z80 emulation started with Udo's excellent z80pack software,
> > which I converted to C++ to fit with the rest of the design.
> 
> I looked a bit through some of the sources, really nice work, great
> to see what others can do with it.
> 
> It would help if you could add some informations where to get the
> Heath ROM's and OS disk images.

Thanks, I'll try to get that updated with detailed information. In the mean time you can check out this other github repro - https://github.com/durgadas311/VirtualH89Accessories

0
Mark
11/7/2016 5:35:48 AM
Reply: