28 Feb
2013
28 Feb
'13
12:45 p.m.
But the burning question is could you fiddle with the extension rom code and use it as a
loadable device driver? After all you could transfer rom BASIC to a disk file and run it
that way.
------------------------------
On Thu, Feb 28, 2013 12:06 PM PST Fred Cisin wrote:
On Thu, 28 Feb 2013, Cindy Croxton Electronics Plus
wrote:
Why can't you just write a small batch
program that references the driver
and the necessary commands, and put it on the startup disk? If not enough
room on a 360K, then you can use a second floppy. We used to do this for
customers all the time, 15 years ago. Also included small start up menus,
etc.
The "driver" is a ROM. You'd have to start by writing a LOADABLE driver.
It would be convenient to have another machine on hand while writing it,
since the "driver" is to get the video to work.
It would be MUCH MUCH easier to install a CGA or MDA card, and contact
Cindy Croxton in Texas and buy one of her "9-pin monitors".
28 Feb
28 Feb
2:42 p.m.
On Thu, 28 Feb 2013, Chris Tofu wrote:
But the burning question is could you fiddle with the
extension rom code
and use it as a loadable device driver? After all you could transfer rom
BASIC to a disk file and run it that way.
It is possible that it consists of a replacement INT10h plus code
that will repoint the 10h position of the IVT (Interrupt Vector Table)
(00000:0040h?) to point to the entry point of the replacement.
If so, then the "loadable driver" should contain the relevant
memory resident code (replacement INT10h?), code to repoint
the IVT 10h entry to point to WHEREVER it ended up in memory,
and then TSR ("Terminate and Stay Resident") To avoid leaving
anything unnecessary and extraneous behind taking up space in
RAM, the "loadable driver" should be a .COM file that starts
with a jump to the loader, then the code to remain resident,
and then the loader, which will set the end point of the TSR
portion to the entry point of the loader. That will waste
the space of a 2 byte relative JMP. But, since leaving stuff
resident is on 16 byte boundaries, we can live with that.
It is also possible to do some clever tricks to load it in as
an "Installable device driver", which means that it will come
in with CONFIG.SYS, rather than wait for AUTOEXEC processing.
On the Sales Tax Genie, I played around with creating a single
.EXE file that could install as a TSR, install as a TSR through
CONFIG.SYS, or run stand-alone either in DOS OR Windoze.
--
Grumpy Ol' Fred cisin at xenosoft.com
4:21 p.m.
On Feb 28, 2013, at 3:45 PM, Chris Tofu wrote:
But the burning question is could you fiddle with the extension rom code and use it as a
loadable device driver? After all you could transfer rom BASIC to a disk file and run it
that way.
Probably not; extension ROMs usually provide services to the BIOS (or
hook interrupts used by the BIOS and run in place of the BIOS
routines) while DOS drivers tend to provide services directly to DOS.
It's akin to the difference between a driver and an application (but
obviously not exactly the same).
Whether you could run a script from autoexec.bat or config.sys to
execute expansion ROM code after DOS boot is another question, but
I have no idea how well that would work after the BIOS has already
handed over control to the OS (I suspect not so well, but I don't
know for sure). You can certainly try jumping to the code location
in DEBUG or the like.
- Dave
7:13 p.m.
On Thu, 28 Feb 2013, David Riley wrote:
Whether you could run a script from autoexec.bat or
config.sys to
execute expansion ROM code after DOS boot is another question, but
I have no idea how well that would work after the BIOS has already
handed over control to the OS (I suspect not so well, but I don't
know for sure). You can certainly try jumping to the code location
in DEBUG or the like.
Trivial nit (learned the hard (usual) way):
It is probably a CALL, not a JMP. At the end of the code, it probably
does a RETF (pop values off of the stack for CS and IP)
--
Grumpy Ol' Fred cisin at xenosoft.com
8:25 p.m.
On Feb 28, 2013, at 10:13 PM, Fred Cisin wrote:
On Thu, 28 Feb 2013, David Riley wrote:
Well, yes. I was being imprecise. Not such a trivial nit
when it comes to making it work!
I always liked the fact that when you told the Apple II
monitor to "go" to a location, it meant a call and not
a jump. I'm not sure why that came as a surprise to
me, but I've certainly used plenty of modern bootloaders
that don't do that.
- Dave
Whether you could run a script from autoexec.bat
or config.sys to
execute expansion ROM code after DOS boot is another question, but
I have no idea how well that would work after the BIOS has already
handed over control to the OS (I suspect not so well, but I don't
know for sure). You can certainly try jumping to the code location
in DEBUG or the like.
Trivial nit (learned the hard (usual) way):
It is probably a CALL, not a JMP. At the end of the code, it probably
does a RETF (pop values off of the stack for CS and IP)
4086
days inactive
4087
days old
4 comments
3 participants
participants (3)
-
cisin＠xenosoft.com -
fraveydank＠gmail.com -
rampaginggreenhulk＠yahoo.com