On Sat, Mar 14, 2020 at 1:36 PM Ken Pettit wrote:
> On 3/14/20 1:09 PM, Tom Wilson wrote:
> > I really like the idea of using the I/O port to talk to the host. +1
> > on that.
>
> VirtualT 1.7 already has two such I/O ports.
>
> IN 20h:
> In VT returns 'V' in A
> On a real M100 returns
On 3/14/20 1:09 PM, Tom Wilson wrote:
I really like the idea of using the I/O port to talk to the host. +1
on that.
VirtualT 1.7 already has two such I/O ports.
IN 20h:
In VT returns 'V' in A
On a real M100 returns 0
OUT 21h:
Set a REAL-TIME milisecond countdown timer value (0-255
I really like the idea of using the I/O port to talk to the host. +1 on
that.
I’m ambivalent on the CPU changes. That is branching into fantasy computer
territory, and while I can absolutely see the use for new opcodes to
support code relocation, that makes the most sense when done in combination
Hi John,
Yeah, I'm thinking about just commiting them in the mainline. The
built-in assembler already supports the extended opcodes that I added.
The emulation will not execute "MOV A,A", "MOV B,B", etc. opcodes as
extended unless the EXT bit is set via SIM 0x80 anyway.
if I ever get time
The debug extensions are a good idea. The instruction set extensions are
less likely to be useful unless we make a model t replacement. If you keep
the feature you can bury it behind configuration that is off by default or
you could leave it in a branch if it became difficult to maintain.
I don't
-
changing the 8085 emulator instead is trivial. Although the bank switch is
probably required to use with BASIC.
From: M100 on behalf of Ken Pettit
Reply-To:
Date: Saturday, March 14, 2020 at 5:52 AM
To:
Subject: Re: [M100] VirtualT support for REXCPM hardware
> 3. At one point I
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
On Fri, Mar 13, 2020 at 10:41 PM John R. Hogerhuis 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 w
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.
Okay, the bug was confirmed, and a fix was proposed.
If you know how to edit and compile the source, the bug is in io.c, lines
1267-1274.
These lines need to be removed:
/* Loop through all LCD driver modules */
> for (c = 0; c < 10; c++)
> {
> /* Check if this driver is enabled */
> if (
I haven't tried any other versions but 1.7, but I did notice that. I tried
playing with all the emulated cpu clock settings but I just assumed it's
old free software and isn't perfect. I never tried any older versions to
notice a regression. I thought it was mostly the widget library mayve being
to
Speaking of 1.7... I installed it next to 1.6, and I've noticed that
booting and running programs on 1.7 is MUCH slower like the CPU
emulation is running at 1MHz or something.
Has anyone else seen this, or am I just going crazy?
Tom Wilson
wilso...@gmail.com
(619)940-6311
K6ABZ
On Thu, Mar
nice!!!
On Thu, Mar 12, 2020 at 3:03 PM Stephen Adolph wrote:
> Well, it's been a learning journey but I've been able to get VirtualT to
> support and emulate REXCPM hardware!
> I'm happy because it means I understand at least something about C and C++
> now ;).
>
> This is a great step forward,
Well, it's been a learning journey but I've been able to get VirtualT to
support and emulate REXCPM hardware!
I'm happy because it means I understand at least something about C and C++
now ;).
This is a great step forward, as now it will be much easier to port Rex
Manager over to the new hardware.
14 matches
Mail list logo
