Deutsch English Français Italiano |
<vb3vpp$3mq2n$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!feeds.phibee-telecom.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Thomas Koenig <tkoenig@netcologne.de> Newsgroups: comp.arch Subject: Re: tiny COBOL, Article on new mainframe use Date: Mon, 2 Sep 2024 09:16:42 -0000 (UTC) Organization: A noiseless patient Spider Lines: 30 Message-ID: <vb3vpp$3mq2n$1@dont-email.me> References: <v9iqko$h7vd$1@dont-email.me> <20240830183742.000065c5@yahoo.com> <vat8uv$1966$1@gal.iecc.com> <XNqAO.174943$FUV7.133561@fx15.iad> <vatf52$2071$1@gal.iecc.com> <jwvjzfxoejb.fsf-monnier+comp.arch@gnu.org> <vauksm$uupg$1@dont-email.me> <vb3rui$1t766$1@dont-email.me> Injection-Date: Mon, 02 Sep 2024 11:16:42 +0200 (CEST) Injection-Info: dont-email.me; posting-host="8931b5407bde990b59eec3041f2a60a5"; logging-data="3893335"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/H+rSjuTkMRudMzt04wEvsjiKsAU8T7Oo=" User-Agent: slrn/1.0.3 (Linux) Cancel-Lock: sha1:jLwG4j0T+UkQhscsJRi3CMSsd24= Bytes: 2317 Terje Mathisen <terje.mathisen@tmsw.no> schrieb: > Thomas Koenig wrote: >> Stefan Monnier <monnier@iro.umontreal.ca> schrieb: >>>> A C64 had 64K 8-bit bytes of RAM, >>> >>> Indeed (tho, IIRC 8kB of those were hidden by the ROM, tho you could >>> change the mapping to hide different 8kB at different time and thus >>> access the full 64kB of RAM). >> >> For doing highly useful things like changing the name of the BASIC >> commands: It was possible to PEEK from the ROM and POKE to >> the underlying RAM. >> >>> >>>> and the floppies held about 1.2MB but they were a >>>> whole lot cheaper than 1311 disk packs. >>> >>> IIRC they held only ~170kB. >> >> And were extremely slow - around 300 bytes per second, comparable >> to a card reader. But fast loaders could improve on that up to 10 kB/s. > > They did that by reading every 1/2 sector, then reassembling after 2 > rotations, instead of having to wait a full rotation between every > sector read? Just reading up on this... it seems that there was a bug in the 6522 I/O controller where the shift register sometimes dropped a bit due to a race condition, and the workaround which was hastily put in place was very slow.