CMOS+ISDOS

*** SENT TO ZX.SPECTRUM *** SENT TO REAL.SPECCY *** SENT TO CODE.ZX ├┤i, All! The watch has already been successfully connected to the Spectrum :-) But it turned out 5 connection options :-( A wealth of choice is good, but their programming suffers. Especially in iS-DOS I don’t want to appear curved programs using only one type known only to them hours. Therefore, there is an idea to develop a unified standard for working with non-volatile clocks or their emulators on interrupts. T.K. all sorts of solutions such as dialing counters or clocks without interruptions are not serious, that is, it makes sense to rely mainly on watches based on a 512VI1 microcircuit or analogues. However, among the good solutions there may be implementations of clocks on specialized chips 176 series, like in the "Pulsar" aon, so I ask you right away if there are any - answer me immediately! 512VI1 is in no way compatible with them. If you count on a watch compatible with 512VI1, then the best way there will be some driver that provides interaction with all registers microcircuit, regardless of the method of its connection or prohibiting access to some registers if this is not possible. In iS-DOS system 3 types of devices are reserved: block, character output, character input. There can be 8 pieces of each. To maintain them and for other purposes there are 5 types of channels: device drivers3 types (24 channels), driver channels of these devices (24 channels), resident tasks (16 channels) and program channels (192 channels). The 512VI1 chip driver requires a separate channel. Drivers block and character input/output devices disappear at least according to because some programs may want to use them as intended. You cannot use channels intended for their use by programs - they can be deleted. The simplest the channels of resident tasks will be used. Those. chip driver will become just a resident task. But not everything is so simple - there is a problem finding and successfully identifying such a driver among others residents. The only reliable way from my point of view is to search for a resident by part of the name reserved only for chip drivers. Identification by channel number cannot be used due to the relocatability of drivers and the fact that the desired The channel may already be busy. The only drawback is for resident the task is allocated only 16 channels, and therefore cannot be More than 16 tasks have been installed. However, for all the time I used iS-DOS case of lack of channels occurred only once. When the driver program is used, parameters can be transferred through registers or memory. In the case of working through a pointer, you shouldpass either the calling program or the driver itself. There is still an important question - with what type of data will the run the program through the driver. It seems to me appropriate to use microcircuit registers as such. Those. yes read/write operating mode flag and register number. In case of recording Recorded data is also needed. The driver should return 2 errors: 1. inability to read the data at the moment - a repeat attempt is required appeal after some time. 2. inability to read or write the data of this register at any time (write protection for example). If the driver does not allow all programs access to all registers (to protect against unacceptable actions of these programs), then to be able to use these registers for programs that this is necessary, it is possible to provide for the transfer of some identification code from the program to the driver before working with it. I invite everyone to clearly define the above issue and write an answer. At the moment I assume this use drivers as described. The driver is called at load address +4 or at an address located in memory with an offset of +2 relative to the address load if it is not zero (see description of the resident task). Call to an address located in a memory cell with an offset of +0 relative to The loading address is made when the driver is removed or moved.When calling a driver to work with a microcircuit in register B, it must The register number is 00...3Fhex. If a recording is being made, then the value is transferred in register A. In case of reading there it is returned result. The write/read operating mode is determined by flag C. 1-write, 0-read. If the driver cannot write or read this register at any time, then it sets the C flag, and if the clock is not ready, then the Z flag is reset. When calling the driver, you must set register C=#FF - this will be a sign that it is not called from the command line, for example to manually install some modes his work. To reduce the time for calling the driver and not lose when calling registers AF and B must be defined once at the beginning of the program in memory the presence of the driver and the address at which it should be called. ; Determining the presence of a driver and address. The program returns ; flag C with error 37 ("no resident task") if the driver ; not installed on the system. The driver must have a fixed ; name - however, if necessary, you can search not only by ; fixed name. ; If the search is successful, the driver launch address is returned. DEFCDA LD HL,NAME ; driver name LD BC,#1651 ; search for channel by driver name LD A,#D8 ; starting from channel ARST 16 ; B channels will be viewed. RET C ; not found A=Error:37 EXX INC HL; to the address in the channel INC HL; with offset +4 INC HL; download address is located INC HL; resident task. LD E,(HL) INC HL LD D,(HL) ; at address with offset +2 INC DE ; relative to download address INC DE ; resident task is located EX DE,HL ; its launch address. LD E,(HL) INC HL; if instead of the start address there LD D,(HL) ; is 0, then the start address LD A,D ; considered download address OR A ; resident task +4. EX DE,HL RET NZ; not 0. this is the start address. INC DE EX DE,HL ; if zero, then the start address is +4. RET NAME DEFM "realtime" ; 8 characters. Driver name realtime.res It wouldn’t hurt to set the driver to interrupts and adjust system date at command line address -3. W!z Be$7 W!$heZ, FK0. Reply to: Kirill_Frolov.sp2813@zxnet.spb.ru

Hi Kirill, In a message of to All (), you wrote: KF> There is still an important question - what type of data will it be KF> run the program through the driver. It seems appropriate to me KF> use microcircuit registers as such. Those. yes KF> read/write operating mode flag and register number. In case of zap KF> we also need written data. The driver should return 2 errors: the idea is fundamentally wrong. The minimum amount of information is 6(7) registers. read without interruption by the adjustment cycle. if you really want to be alone - you must enter at least the image location parameter. but why make 6 calls, When is one enough? and about those not related to the clock and especially control registers in general There should be one opinion - it is simply harmful for a user program to touch them. Moreover, green amphibians can throw some kind of surprise at this... KF> It would be a good idea to set the driver to interrupts and adjust it KF> system date at command line address -3. Unfortunately, it won't be easy to check how many programs will take offense at the premises system time in the same place -5 ;(. although ideologically both have a place on the levelbelow in order to update the corresponding fields for modified files. although if take into account the actual unity of all three lower levels (see also accompanying fiction), then the latter can be neglected.. As for adjustments, it would be more correct to do it only immediately before reading. when requesting the address of the corresponding vector with clarification "in this area _image_ of data on the state of the moment of interrogation." But if you still modify DOS to independently update the descriptor fields file, then why do you need datatime in DOS format? ;) Bye, Michael.

Hi Kirill, In a message of to Michael Kondratyev (), you wrote: KF> microcircuit in full. Of course, you can have 8 registers at once KF> read. not mona, but noona. ;) KF>> It would be a good idea to set the driver to interrupts and adjust it KF>> system date at command line address -3. MK> unfortunately, it will not be easy to check how many programs will be offended by MK> placement of system time in the same place -5 ;(. although ideologically for both MK> place one level below KF> The command line parser will be very buggy. Not allowed. With this, everything can be solved simply - you never know where else you can find two bytes (at least in you can paste the code). I wonder how many _application_ programs know about it. I haven't met any of them yet (everyone had enough value hl' returned disassembler). That's why I thought about a place for time. KF> After all, the date must be entered in the file manually (in the sense of KF> copy line-3 to fname+30. and who said that this is _necessary_? That's not how it's done. The correct answer is file the system does not support setting the date, although there is reserve for the future (or rather fornever) available. in the right systems there are generally at least three dates for each files are logged - creation, last modification and last access. KF> I don’t know. But there are two problems - reading the date/time in normal mode KF> and writing them into the file descriptor in a tricky format. do you mean cunning? KF> Here’s another question - nowhere is it written in what format the date is KF> store :-( Maybe like in MS-DOS? But it’s not yet clear how it should KF> in MS-DOS and 2 bytes there or more? it is stored as in msdos. If you forgot, let me remind you: The date consists of the year, month and day packed into 16 bits as follows: Bits Meaning bits 0-4 Day (1-31) bits 5-8 Month (1-12) bits 9-15 Year (0-119 representing 1980-2099) The time consists of the hour, minute and seconds/2 packed into 16 bits as follows: Bits Meaning bits 0-4 Seconds/2 (0-29) bits 5-10 Minutes (0-59) bits 11-15 Hours (0-23) Bye, Michael.

Hello, hello Kirill! One day, in the chilly summer, something around (27-07-98/00:55:00) Kirill Frolov once wrote to me. KF> ├┤i Vitaly & Michael ! [sk] KF>>>> :-( It was a pity 1 bit per second [extra sk] VV>> And if you chop something off, it depends on the year :) [super sc] KF> Yes, the lamers invented this. Here MK wrote that in unix everything is in seconds KF> has been stored since 1960 - everything fits into 4 bytes without any problems. At 133 s KF> another year is enough. Quote from the book: "The official birth date of UNIX can be considered January 1, 1970. It is from this moment that any UNIX system counts its time." 1970+133=2103. We get the problem of 2103! Although, will anyone remember about UNIXes in 2103? In Amiga, the date is stored everywhere in the form: day, minute, second and everything is in the form of long (i.e. 4 bytes). It's easy to calculate the max value of a date :) With temporary-endless greetings, evil Vitalik AKA Dark / X-Trade