Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Bart Newsgroups: comp.lang.c Subject: Re: Top 10 most common hard skills listed on resumes... Date: Tue, 10 Sep 2024 11:52:57 +0100 Organization: A noiseless patient Spider Lines: 74 Message-ID: References: <87mskvuxe9.fsf@bsb.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 10 Sep 2024 12:52:56 +0200 (CEST) Injection-Info: dont-email.me; posting-host="dcf5d3c489b4c68fb3a29f50d34b534a"; logging-data="3046621"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX194XITTDwWLusu+sTcq+JUc" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:hrWcQ4w5m+qlxeaxzDGgP5lcmG4= Content-Language: en-GB In-Reply-To: Bytes: 4309 On 10/09/2024 05:40, Waldek Hebisch wrote: > Bart wrote: >> I've looked at half a dozen hits for 'forth postpone' and I still don't >> understand what it does. Apparently something to do with compiled mode. >> >> I wouldn't know enough to confidently implement it or use it. > > Silly example 1: > For a non-advocate of Forth you have a lot to say about it! I've archived your post for if/when I get back to that project. (If I ever use Forth, it'll be on my own terms. I just tried it to see if it's still breathing: c:\qapps>qq forth Bart-Forth Type bye to stop > 2 2 + . 4 > bye So it looks like I already thought of it as my version.) >>> To give more background, bare ZX81 had 1kB RAM (including video RAM). >> >> You must mean /excluding/ surely? Otherwise there wouldn't be much left >> from 1KB! > > There is not much left. But there is a trick: boundary between > video memory and rest is movable, as you fill other part available > screen area shrinks. It does not take long time to have machine > completely filled out with no free space left (and IIRC some > small screen area for out of memory message) So that meagre 1KB had to be shared? The Z80 designs I did (for my own use and when I had a job developing commercial machines) never used used tricks like that**. I never had to work within very tight pricing, but I would have considered such a machine unviable other than for experimenting. (** Well, part from using partially-populated bytes. For text memory it was for cost. For video memory I used 8KB but addressed as 16K 4-bit bytes. This was so that in greyscale mode (it had 256x256x1 and 128x128x4 modes), each pixel had its own address for convenience. In that mode, this circuitry was also used for TV frame-grabbing.) >> But both only had tape storage so tools were memory-based. > > I wonder, did you have any ROM? Or battery backed RAM? Otherwise > how tape reading worked? In micros I know about tape reading > was via software, on Spectum this was more than 100 bytes. > It would be rather tedious to key in tape loader via console switches. > Old mainframes had I/O in hardware, but that was rather large > circuitry. The first version used circuitry (shift registers and counters) to read and write cassette tape, at around 300bps. I think the same circuitry was also used in single-step mode to manually load in data a bit at a time, or examine memory after a run (since there was no display at first, just on/off LEDs). Using software, I could read and write tape at 1200bps. At some point I also programmed a ROM (using an ad-hoc arrangement as I had no proper programmer) to provide software on power-on.