Isn't ProDOS 8 v1.8 "real" enough for you?

I custom-built Randy Spurlock's apl2em (@simtel) in masm 5.1, it runs significantly faster on a 486DX2/50. Try it on a P3/666, er, 667, it should soar.

MASM 5.1??? You mean for CP/M? Now, that would be interesting!

Uli

PRODOS?

What I've got is a MUCH earlier version for the IIc. I'm not sure I want to go back that far, having established that it's virtually impossible to generate useful work (individually controllable signals for real-time control) with a IIc. Once I figured that out, I removed the socketed CPU and detachable keyboard, and tossed the rest of it, CRT and all. (Gotta clean out the rubbish, doncha know!)

I've still got a few II+'s and a raft of boards I'll have to decide on.

Uli

MASM 5.1 for DOS.

Oh, well ... it would be interesting to see how the 6502 simulates on a Z80. A 6502 emulator for the PC should be easy enough to emulate cook up in 'C' since that's pretty efficient and since the 80x86 is such a vast superset of the 650x core. What's more, the model should easily mate up with the 'C' pointer structure that can easily emulate the various addressing modes. It must have been somewhat painful to do that in assembler.

If you carefully write the simulator, not for an Apple, but for the CPU core, you can pretty easily port it to VHDL and implement it in a CPLD or FPGA. You might find that to be fun.

Uli

Considering also that Spurlock wrote it in 1988 for a 286, yes, it must have been a headache. I wouldn't know, I just assembled it ._.,

I'm still not clear on what it is. Do you mean it's an APPLE-][ simulator, or a 6502 simulator?

Uli

It's an Apple II+ emulator. It contains a 6502 emulator (because what's an Apple II emulator without a 6502 emulator core?)

There are lots of ways of emulating a circuit. You can do it top-down, i.e. behaviorally simulate the entire system, or you can do it bottom-up, simulating each circuit element individually as it behaves in the system. Of course, you can also simulate groups of components that behave in a well-characterized way.

A 6502 simulator, that that correctly and precisely emulates the cycle-by-cycle behavior of the CPU with respect to the changes of signals on the device pins, would interest me. A program emulates the behavior of the Apple-][+ as a system would not.

Uli

I wish I knew more about the opcodes, kind of like
"$60 (no parameters): RTS (Returns from subroutine)"
"$4C (word low-endian [add]): JMP (Transfer control to address add)"
that would have to be relatively detailed, because I don't know jack about assembler...but then I could write a 6502 emulator easily...

I was meaning a more detailed emulation, i.e one that precisely emulates the low-level behavior of the CPU itself. For example, if you read location $8000 indexed by X, the CPU does a dummy read cycle on $8000 before reading the target location at $8000+[X]. This may seem like a minor point, but, for example, if you are emulating the actual performance of the processor, it sheds light on why some instructions take more bus cycles than others. It also will explain why indexed access to a peripheral device's status register will clear the data-available bit in the status registerd if the base address is the data register. I didn't learn this by reading a manual, BTW.

Uli

>It also will explain why indexed access to a peripheral device's
>status register will clear the data-available bit in the status
>registerd if the base address is the data register.

I don't know why I would ever do that, but thanks for pointing that out. Your comment may save me (or someone else) some time someday. I remember reading of similar problems caused by the invalid read by the NMOS 6502 in indexed addressing across a page boundary. I'm sure it could drive you absolutely nuts trying to debug it!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Well, if you ever build hardware for the 6502, it helps to know what the signals on the IC are doing, stroke for stroke. That's why an accurate and precise simulator is not without it's place. Many years ago, I wrote a model for a digital logic simulator, that used a pprecisely specified set of signals related to a clock, not as a running microprocessor but as a stimulus. It was a major pain, because every single event had to be scheduled and specified individually.

Nowadays, 6502's aren't terribly relevant any more, though I'm surprised they aren't supported by a lot more well implemented IP cores than they are. The reason the 6502 became so popular was that it was inexpensive. The reason for that was that it was cheap to produce, because it was designed to use less silicon than its contempraries. The reason for that was the way in which it used what it had. Those same economies should make it attractive to implementors using CPLD's and FPGA's. The open source cores I've looked at don't do that. They save enough, over other cores, on the internal registers that it makes them notably smaller than, say, a Z80.

I feel the "real" economy comes from the use of the ALU to do the register and address arithmetic, in addition to the arithmetic on data operands. I've yet to see one that does that, however.

The business about indexing from the data to the status in an ACIA was a published oddity back in the late '70's. I'm not exactly sure why one would want to do that, but if you're using code someone else has written, it's easy to assume they didn't do something that would categorically fail. If they don't know any more than you, it's not a safe assumption.

Uli

>The reason for that was that it was cheap to produce, because it was
>designed to use less silicon than its contempraries. The reason for
>that was the way in which it used what it had. Those same economies
>should make it attractive to implementors using CPLD's and FPGA's.
>The open source cores I've looked at don't do that. They save
>enough, over other cores, on the internal registers that it makes
>them notably smaller than, say, a Z80.

One of the Steves (Jobs or Woz, I don't remember) said the 6502 was in fact chosen for the Apple because of its low cost. But I would have to add the high power-to-complexity ratio to the list of attractions.

Jack Crenshaw is a respected authority in embedded programming. In an article in the 9/98 issue of Embedded Systems Programming, he talks about different BASICs he used in the 70's and 80's, and said the 6800 and 6502 always seemed to run them faster than any other processor. (I believe the 80 family was running at higher clock speeds too.) Quoting two paragraphs:

"To me, the 8080 and Z80 always seemed to be superior chips to the 6800 and 6502. The 8080 had seven registers to the 6800's two (plus two index registers). The Z80 added another seven, plus two more index registers. Nevertheless, I can't deny that, benchmark after benchmark, BASIC interpreters based on the 68s consistently outperformed those for the 80s.

"The biggest problem with the 68s was that they had no 16-bit arithmetic. Though the 8080 and Z80 were basically 8-bit processors, at least they had 16-bit registers (three for the 8080, eight for the Z80), and you could actually perform arithmetic in them, shift them, test them, and so on. You couldn't do any of these things with the 6800 or 6502, which is one reason I still don't understand, to this day, how the 68s could outperform the 80s in benchmarks."

(End of quote) After learning the 65c02's instruction set and bus usage, I remember being impressed by the relative inerficiency of the 80 families, including the greater number of clocks the 80's needed to carry out instructions, the lack of decimal arithmetic and implied compare-to-0 in various instructions, and so on.

Since then I've used PIC microcontrollers for a couple of products. The attractions include lots of I/O options, on-board everything, low price, easy programmability, and they're available off the shelf at many distributors. But the one thing I absolutely hate about them is their RISC microprocessor core that Microchip touts as being so wonderful. Compared to the 65c02, it's decrepid. The limitations require all kinds of programming jerry-rigs to get around, and then I find that if the job is small enough for them to do it at all, they take twice as many clocks to do it as a 65c02 core would take.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?