Recent

Author Topic: A Challenge for Lazarus Gurus  (Read 1198 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 8453
Re: A Challenge for Lazarus Gurus
« Reply #15 on: June 15, 2025, 05:38:11 pm »
Almost looks like what could help the cause is a File Monitor, one that monitors folder/Directory activity and notifies the main app so it can go can check changes made to inner files.

I know that can be done in Windows because I have code for that which runs in a secondary thread and notifies the main thread of an event taking place.

FAM (File Alteration Monitor) on unix: I think I've posted an example before now. However I can't for the life of me see how that would help with the problems of indexing and seeking into existing files.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MarkMLl

  • Hero Member
  • *****
  • Posts: 8453
Re: A Challenge for Lazarus Gurus
« Reply #16 on: June 15, 2025, 09:14:04 pm »
Hmmn... catalog-set-member: sounds familiar, even if I was with the competition.

This leads to the possibility of appending the entire source-file to the end of the index structure.....

No, not like that. Any modern OS will allow you to seek rapidly to the end of a file, so /right/ at the end you put a "magic number" indicating metadata version etc., below that you put the metadata, below that you put the indices and right at the bottom is the original data.

Code: Pascal  [Select][+][-]
  1. // Data storage here. Each 48-bit machine word actually expanded to 64,
  2. // with the remainder used for VM breakpoints etc.
  3. //
  4.   Tsuper=       record                  (* Last segment in master or shadow file *)
  5.                   data: TsegmentData;
  6.                   dirty: word;          (* 16 bits, MSB zero if clean 1 if dirty *)
  7.                   fingerprint: word;    (* 16 bits, derived from master file    *)
  8.                   myStoreCksum: word;   (* 16 bits, all checksums except superblock *)
  9.                   parentStoreCksum: word; (* 16 bits, copied from parent file   *)
  10.                   mySuperCksum: word;   (* 16 bits, checksum including magic    *)
  11.                   parentSuperCksum: word; (* 16 bits, checksum from parent file *)
  12.                   magic: longword       (* 32 bits, MSB always clear            *)
  13.                 end;
  14.   Psuper= ^Tsuper;
  15.  

If you don't do that, then any notes that you've previously written ("I know that I can find the magic potion 314159 bytes in") are invalidated, and any change that you make to the index etc. structure (e.g. adding another field) will be more difficult to recover from (I'm assuming that you have enough data to make indexing relatively expensive).

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

tfurnivall

  • New Member
  • *
  • Posts: 49
Re: A Challenge for Lazarus Gurus
« Reply #17 on: June 15, 2025, 10:48:42 pm »
OT

Do I detect a Burroughs machine? (48 bits - plus a few)

And did the competitor's name have only two characters?

Perhaps you've used the product I'm thinking about recreating for a PC....
Tony

MarkMLl

  • Hero Member
  • *****
  • Posts: 8453
Re: A Challenge for Lazarus Gurus
« Reply #18 on: June 16, 2025, 09:13:22 am »
Port of Paul Kimpel's B5500 emulator to Pascal, using threads for the separate subsystems. Master plus shadows for the disk, some of the peripherals replaceable dynamically e.g. the paper tape reader and writer. SPO on Telnet, /lots/ of debugging from the engineering console, and a dump of internal state to logic analyser files if needed.

I'm /very/ slowly zeroing in on a race condition caused by the multithreaded implementation (i.e. probably reflects something that wouldn't happen in Paul's single-threaded Javascript), if I can fix that and tidy up some peripheral weaknesses I'll hopefully learn enough to be able to recompile the MCP and then finish off the FPM so I can cluster several systems.

Part of the significance of this is that it's obviously the machine Wirth used at Stanford. I'd quite like to have it running next to a Hercules-based VM system: that would be a bit of an historical liberty since Stanford ran OS/360 after McCarthy gave Burroughs the boot, but being able to exchange (files representing) tapes etc. would be satisfying and the two OSes- MCP and VM- are probably the most significant ever.

I was assuming you were from the IBM tradition with your file-level naming...

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018