X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f996b,9c5db9e6be40caff X-Google-Attributes: gidf996b,public X-Google-ArrivalTime: 2001-02-22 00:58:06 PST Path: supernews.google.com!sn-xit-03!supernews.com!nntp.cs.ubc.ca!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.stealth.net!24.30.200.2.MISMATCH!news-east.rr.com!news.rr.com!cyclone.kc.rr.com!news.kc.rr.com!cyclone3.kc.rr.com!news3.kc.rr.com!typhoon.kc.rr.com.POSTED!not-for-mail Newsgroups: alt.ascii-art From: Nate Dannenberg X-X-Sender: Subject: Re: OT: Spamfighting (was: All YOUR Romantic Needs - Relationship101.com 9857) In-Reply-To: <9be89tsfi8cp98avrfjb8qlh2t41jghc40@4ax.com> Message-ID: References: <2g3u8tgim9e14esk4a7nh9mesg9o6d3oas@4ax.com> <60u09t8aabjgmcqgi4fmimgsadebq2tp0j@4ax.com> <9be89tsfi8cp98avrfjb8qlh2t41jghc40@4ax.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Lines: 116 Date: Thu, 22 Feb 2001 08:56:36 GMT NNTP-Posting-Host: 24.166.131.83 X-Complaints-To: abuse@rr.com X-Trace: typhoon.kc.rr.com 982832196 24.166.131.83 (Thu, 22 Feb 2001 02:56:36 CST) NNTP-Posting-Date: Thu, 22 Feb 2001 02:56:36 CST Xref: supernews.google.com alt.ascii-art:4544 I wrote: > >After all this noise about emulation, would you believe that I don't > >emulate on a regular basis? :) And Peter Replied: > After seeing your page (and hearing Modplay 128, great stuff!) i would! > > But will i see you there? Nope, haven't visited it for ages :) > >I use the real thing when it's called for, and besides, what's Fort > >Apocalypse anyways? > > Fort Apocalypse is nothing... Heh, the Fort Apocalypse thing was a joke running in c.e.c, though I'm not entirely sure how it originated. > ...compared to the games that game out on each issue of GO!64 and > PlayTime. Go64! is a good resource for C64 users, no doubt of that :) > Oh, and i always liked demos. It's amazing what a good programmer can > squeeze out of a 0.96 MHz computer with only 16 colours and 48K RAM > (+16KB of kernal, copied to RAM) PAL is ~0.985 MHz, NTSC is 1.022727 MHz. :-) The machine has ~64K of regular 8-bit RAM, 1K of 4-bit wide RAM for the VIC color map, 20K of ROMs, and 3K of I/O devices (much of which is not actually allocated, but contains mirrors of real, allocated blocks). The ROM code is not copied to RAM at all, in any configuration, except for one exception (see below). You can if you want, but then you're giving up valuable RAM for your program code, and the RAM isn't any faster than ROM. >From the 6510 CPU's viewpoint [1]: 0000/0001: Processor's RAM/ROM/I/O banking register, and datasette. 0002-00FF: Zero Page RAM 0100-01FF: Processor stack 0200-03FF: RAM: BASIC/Kernal variables and such 0400-07FF: RAM: Default location for Text screen 0800-7FFF: RAM: BASIC program space 8000-9FFF: RAM: BASIC program space, or external function ROM A000-BFFF: BASIC ROM, or RAM if switched out, or external function ROM C000-CFFF: RAM: Unused by the OS, good place for small ML programs. D000-DFFF: I/O Devices [2] D800-DBFF: Color RAM, 4-bits wide [2] DC00-DFFF: More I/O devices [2] D000-DFFF: Character ROM, or RAM [3] E000-FFF9: Kernal ROM, or RAM if switched out, or external function ROM FFFA-FFFF: Interrupt vectors [4] [1] In all cases, if a ROM (whatever it's origin) is visible to the processor, any write to that ROM area will actually be directed to the RAM hidden under the ROM, and reads will return data from the ROM, of course. The VIC video chip can't see the BASIC and Kernal ROMs at all, in any mode. The Character ROM is always visible to it regardless of the setting of $0000/1, and there are echoes at $1000 and $9000 that only VIC can see. [2] In the case of the D000-DFFF area, the two blocks of I/O devices and the color RAM are treated as a single unit when it comes to switching them out. [3] If I/O devices are switched out, the Character ROM is visible in this area instead. You can further switch that ROM out to reveal 4K of RAM underneath. [4] Interrupt vectors are normally taken from the Kernal ROM when it's switched in. Otherwise, they are taken from RAM. These are the NMI, Reset, and IRQ vectors, two bytes each. When the entire ~64K is made visible (all ROMs and I/O switched out), a total of 518 bytes of the now CPU-visible space are considered special- purpose memory for various things: The two bytes of the processor's banking register and datasette interface are actually an on-chip I/O port, part of which connects to the memory map decoder chip (the PLA), to handle RAM/ROM/I/O banking. The 254 bytes of ZeroPage normally contain vectors, pointers, temporary storage, and other such stuff, but you can also put code here. In fact, on start up, the BASIC interpreter places a few bytes of the ROM's "CHRGET" routine here for speed. The 256 bytes of the Processor Stack. Code can go here, but it's not a smart idea unless you're really hurting for program space. The 6 bytes of Interrupt Vectors, as above. Also, at least 1K of RAM must be allocated somewhere in the memory map for the screen, the default being at $0400. Code is often placed right in this RAM (and blacked out by filling Color RAM with 0's), often as a temporary place to run it from, like in a depacker/decruncher routine. No need for the routine once the program starts, so why not overwrite it with display data? :) -- ___________________________________ _____ _____ | _///@@@| | | natedac@kscable.com /'//ZZ@@|____ | | |'''/ |'/@7 | | http://home.kscable.com/natedac |`'| `~~' | | | `| .--. | | C64/C128 - What's *YOUR* hobby? | `\____|___\ | | \_ | | |___________________________________ \_____| _____|