Hey Guys,
I have a real M100 on my desk and will load up a long BASIC program and
time the listing of it. Then do the same in VirtualT to dial in the
delay. I would like for this to be in there and be accurate, otherwise
the VT emulation is not represenative of the actual hardware.
Stephen Hurd converted the SourceForge svn repo to a git repo (Thank you
Stephen!) and has been making code updates to fix some warnings for
Clang, C++11, etc. I am going though my local minor changes that I have
made over the past few years (there aren't that many, but I'm going file
by file to be sure) and merging those into the git repo. Then I will do
this timing test and dial in the correct delay factor for the LCD
drivers. Should be sometime today I believe as I have gone through most
of the files.
A couple of changes I have made in my local emulation that I'm not sure
if I should checkin to the released VT:
1. I added some debug IO OUT ports that allow the 8085 ASM code to
print to the VirtualT debug console.
a. OUT 23h: Print the A register as an ASCII character.
b. OUT 25h: Print a NULL terminated string at (HL).
c. OUT 26h: Print the A register as an 8-bit decimal value.
d. OUT 27h: Print HL as a 16-bit HEX value.
2. When working with John Hogerhuis on his CloudT Cassette load
emulation, I added the ability to load text files via the cassette port
in VirtualT. This patches the ROM to make this happen.
3. At one point I was working on an FPGA emulation of the M100, and in
that Verilog code had extended the 8085 instruction set to do relative
branches and extend the address range to 24 bits. Actually had it
working in simulation with a patched ROM. The ISA extensions are
enabled by setting the upper bit in A (0x80) during a SIM opcode. Then
non-useful (and unused in the main ROM) opodes like MOV A,A and MOV B,B,
etc. are re-mapped as opcodes like LJMP (long jump), LCALL and Bcc, Bnz
(relative branches).
Thoughts on checking any of these in for VirtualT 1.8?
Ken
On 3/13/20 11:07 PM, Tom Wilson wrote:
On Fri, Mar 13, 2020 at 10:41 PM John R. Hogerhuis <jho...@pobox.com
<mailto:jho...@pobox.com>> wrote:
Good sleuthing.
But isn't that more of a workaround than a fix? Since it reduces
the accuracy of the emulation.
Why does that code cause it to bog down?
-- John.
Ken is the one who introduced the code, and he chimed in when I filed
the but report on the SourceForge page.
Short version is that he introduced this to make the emulation more
accurate (yes), but he went too far in that he introduced way too big
a delay. In the official fix he checked in, he actually turned down
the delay. I prefer to just have the 1.6 behavior for now until
someone can verify the actual time involved.
