Lara Croft cmos driver

The description of the subject says that #5b00 - init, #5b02 - time recording, #5b04 -
reading time every second.

In my driver at the beginning it says:
#5b00 jr read
#5b02 jr write
#5b04 ret:nop

And everything works correctly. So the question is: who is hanging something on
#5b04? Or can you safely use #5b00 to read the time?

ZXNet: 500:8462/1 ~/ <~ http://zs80.chat.ru/
Fido: 2:5057/21.93 /_ _> ftp://zx-museum.org.ru/zs/

Sat 26 Jan 2002, at 18:49:04 Sergey Zotov told All about Lara Croft cmos driver

SZ> In my driver at the beginning there is:
SZ> #5b00 jr read
SZ> #5b02 jr write
SZ> #5b04 ret:nop

SZ> And everything works right. So the question is: does anyone hang anything on
SZ> #5b04? Or can you safely use #5b00 to read the time?

I use #5b04. There, it seems like the driver is being initialized. In
in particular, for those machines that need to
enter something in #eff7 to activate access to Cmos, and Lara uses this port (which, by the way,
write-only) also to activate 512*192. I don’t remember exactly now, and I’m too lazy to load the debugger, but it seems that when I enter #5b04, a
copy of what Lara herself pushes into #eff7 (video mode) is added to the battery.

Bye, Sergey.
WBR, Vivid^Brainwave.

I looked at the log now: if #5b04 is set to ret, then the clock runs programmatically, i.e. on
im2, and during disk operations they begin to lag.

SZ> And everything works correctly. So the question is: does anyone
SZ> hang something on
SZ> #5b04? Or can you safely use #5b00 to read
SZ> time?
not

JTN/4D

SZ> And everything works correctly. So the question is: who is hanging something
SZ> on #5b04? Or can you safely use #5b00 to read
SZ> time?

If I’m not confusing anything, then in Lara’s description it is written that if the address #5B04
is as you wrote above, then the clock will tick software in Lara itself,
that is, it will slow down when accessing the drive etc. And the initial value
for the clock is taken when accessing #5B00 when starting Lara. I had somewhere a driver for Lara under SMUC, where #5B04 actually reads the SMUC clock. But
I couldn’t find him :(

Stanislav

On 27 Jan 02, Aleksey Malov wrote to Sergey Zotov:

AM> I use #5b04. There, it seems, the driver
AM> is being initialized.

initialization is in #5b00. 100%

AM> In
AM> in particular, for those machines that need
AM> to enter something in #eff7 to activate access to
AM> Cmos, and Lara uses this port (which, by the way,
AM> write-only) also to activate 512*192. I don’t remember exactly now,
AM> and I’m too lazy to load the debugger, but it seems that when entering #5b04, a copy of what Lara herself pushes into #eff7 (video mode) is added to the battery
AM>.

I understand. I'll fix the driver, I'll have time to read from #5b04.

SU> If I'm not confusing anything, then in Lara's description it is written that if the address
SU> #5B04 is as you wrote above, then the software clock will tick in
SU> Lara itself, that is, it will slow down when accessing the disk drive, etc. A
SU> the initial value for the clock is taken when accessing #5B00 when starting
SU> Lara. Somewhere I had a driver for Lara under SMUC lying around, where #5B04
SU> actually reads the SMUC clock. But I couldn’t find it :(

In short, at address #5b04 you need to write nop:nop, because from #5b06 reading
SMOKY hours begins.

Throw out the poop.

SZ> And everything works correctly. So the question is: does anyone hang anything on
SZ> #5b04? Or can you safely use #5b00 to read the time?

Starting with version 3.8 there is support for a driver for Cmos clocks.
The driver must be no more than 256 bytes and must be
compiled from address #5B00. The driver has three entry points:

#5B00 - initialization of the clock + loading time into the buffer
addressed by the HL register pair. Also in register
A at the input is a copy of what was sent
to port #EFF7.
#5B02 - recording time from the buffer (HL) to the clock. This procedure
is called only after exiting the time editing menu
with ENTER
#5B04 - This procedure is called every interrupt. It should
update the time in the buffer at address HL. At the output
the procedure must set the NC flag so that
the time redraw occurs (C - do not redraw at
this interrupt). If #C9 is located at this address, then
the native time processing procedure will be called.

WBR, Jason.

[Team Death metal] [Team Obituary] [Team Friday 13th] [Team Huge Axes]

29 Jan 02 21:02, Sergey Zotov -> Stanislav Udin:

SU>> ​​Lara's launch. Somewhere I had a driver for Lara under SMUC lying around, where the SMUC clock is actually read according to
SU>> ​​#5B04. But I couldn’t find it :(

Try it. If anything, write.

section 1 of file cmosdrv.$c < uuencoded by Dos Navigator >

sum -r/size 34156/405 section (from "begin" to "end")
sum -r/size 63193/273 entire input file

ZXNet: 500:8462/1 ~/ <~ http://zs80.chat.ru/
Fido: 2:5057/21.93 /_ _> ftp://zx-museum.org.ru/zs/