Login

Forum Help Post Your Message Username: (Login) Topic: Message:   Previous Messages Posted By indi on 2007-07-15 13:30:36  Re: Plus/4 Expansion port... Got it - thanks! I've managed to get my external RAM expansion proto-type working, which is pretty neat (for me anyway). It requires no internal modifications and works on a stock Plus/4. You can see it on my blog: http://dailly.blogspot.com/ Posted By siz on 2007-07-15 07:23:31  Re: Plus/4 Expansion port... Yes, they are active only when a read is addressed towards the external ROMs. Posted By indi on 2007-07-15 04:10:34  Re: Plus/4 Expansion port... Quick question about some of the output lines.... C1HI, C1LOW /CS1 /CS0 I don't seem to be getting any output on these lines. I've tried writting to $fddx but still nothing. Am I missing something? Are they only active on READ? Posted By MasK on 2007-02-12 14:52:23  Re: Plus/4 Expansion port... Siz! Your monitor's capablities are sounds really cool,but I can't find it in your releases..? You plan to make the source public,or will you do the modifications yourself..? I think,we don't have to worry about using some ram,freezer code can save ever all memory contents into external ram... But it's becoming little tricky,when user loking into freezed memory,monitor must show saved data,and not the actual memory content. The trace and exetucion are the hardest part...we need to copy back and then execute the freezed code.If we reached a breakpoint,freezer should come in again,maybe single instruction trace will pretty slow from freezer. We can't care about memory usage...one tricky code is exist,which is not traceable,or restartable without some hacker-skills.. If a program is joking with the stack,changing and checking it's content periodically,(or placing executable code into the stack!),we can't do anything,some bytes are accidentaly loosing,when brk execution pushing some data onto the stack. Posted By siz on 2007-02-11 07:34:23  Re: Plus/4 Expansion port... I made a monitor program that is executed from ROM image. Currently it uses a lot of Kernal calls (for I/O) and some RAM (100-200 bytes) but it can be changed to not use any of them. For example mapping some RAM to $fe00 and backup uses zero page addresses there. It is about 8-10 kbytes in length, can read from RAM/ROM and IEC devices. Has built-in character-set, character-screen, bit map searchers, code relocator, single step debug, illegal code handling in assembly. Can interpret binary/decimal/hexadecimal numbers. It can also use a PC style parallel printer on user port. It's source in Csory's Macro Assembler format so it can be expanded any time. Posted By NinjaDRM on 2007-02-11 04:17:19  Re: Plus/4 Expansion port... If this is of any interest. Doc Bacardi once worked on porting his SuperCPU-monitor "DreaMon" to the RetroReplay hardware. It was only stopped because of some bugs within the RR hardware. I think he would give away the sources (if he has not done so already). Of course, someone still has to adapt it to plus4, dunno if it is worth the trouble. But on the other hand, sources are always nice I can ask him next time we speak... Posted By MasK on 2007-02-10 07:35:29  Re: Plus/4 Expansion port... This should work,I'm sure! I will try,as soon I can... While looking for a better monitor source for freezer,i just found this: - "FÉK", "potencióméteres gépsebesség lassító" (C16, C116, Plus4) - non-maskable RESET button, external module (C16, C116, Plus4) (!!!) Here: TomHX Anybody know anything about this cheats? They was ever commercial,or only single "prototypes" for TomHX's personal purposes? Me though, somewhere, sometime already I heard about "FÉK"..but I can't remember more details. Posted By TLC on 2007-02-09 02:48:33  Re: Plus/4 Expansion port... Well... actually, these are just ideas, until someone implements them in metal . So, at the moment, I'd call this a "dead end", or "a bunch of ideas", rather than a "design"... whatever. I'd actually be happy to see someone implementing a freezer, and if he could make use of these ideas, that's a bonus... would be happy about that... whatever... Posted By MasK on 2007-02-08 16:48:27  Re: Plus/4 Expansion port... Well,TLC...I can only say one word:brilliant logic You just designed a new, totally undetectable and undefensible freezer cartidge right now, congratulations!! Posted By MasK on 2007-02-08 16:35:22  Re: Plus/4 Expansion port... Sorry about the "guess" joke The second (DMA based?) mechanism isn't clear for me...my idea wasn't correct,I can see it now... But maybe we have to "back to roots",and think again everything... Thanks to TLC summarizing all cases...there must be a simple way,to do this!! ""(E.g. the next CPU read cycle after a single CPU write cycle is predictably an opcode fetch of the next instruction)."" I think,this is our point..not too hard to find out,if only single write happen,and a read is coming now....this is the moment,when we need to pull data bus low. Interrupts+dma are can't affect this..every code must use some simple memory writing instuctions. If we don't missing something,this is the perfect freezer solution,only we need now a better monitor and some additional code for freezer's functions. Posted By TLC on 2007-02-08 15:53:58  Re: Plus/4 Expansion port... Yep... that's true, if it relies upon IRQs, or DMAs. Still, I think, it's possible to do without either. Single write cycles are predictably followed by an opcode fetch. These single write cycles _can_ be catched IMHO... it would need some clever knowledge of the bus signals and probably three flip-flops. What we need? Activate something on a _read_ cycle, which is preceded by a write cycle, which is preceded by a read cycle. Let's use three flip-flops (or a shift register with three bits, whose first bit can be loaded without an implied shift at the same time, but let's just stay with flip-flops for the sake of simplicity). Let these be A, B, and C. B is loaded into C and A into B at the end of every CPU cycles (ie. it's shifted on all CPU cycles, and it's done at a time when it won't disturb our circles). Find or create a signal that goes active in all CPU cycles at about the time or slightly later when r/w' drops on write cycles. Upon the active edge of this signal, store the state of r/w' into A. Also, at this very minute, (C & !B & A) (or for the sake of speed, C & !B & r/w' itself) will tell us if it's "our time" (e.g. D0-D7 can safely be pulled low). "A" might be unneccessary, if r/w' is still active at the time the "shifting" signal goes active (ie. r/w' could be stored to B directly, after B had been shifted to C). Maybe, it's just the way to go, as we also need to know the "end" of "our time" (e.g. when D0-D7 must be released) so we need a signal like that anyway. This would get active sooner or later, unless the program executed no write opcodes (pretty unlikely ) or it executed rmw opcodes or JSRs or BRKs only... . Posted By Bionic on 2007-02-08 13:42:24  Re: Plus/4 Expansion port... Ninja: Yes, that is also my understanding. So now we got two freezer algorithms. One fails when IRQ is off and on fails when the screen is turned off. My guess is the next generation of "protectors" will just turn IRQ and screen off Posted By Bionic on 2007-02-08 13:42:03  Re: Plus/4 Expansion port... Ninja: Yes, that is also my understanding. So now we got two freezer algorithms. One fails when IRQ is off and on fails when the screen is turned off. My guess is the next generation of "protectors" will just turn IRQ and screen off Posted By NinjaDRM on 2007-02-08 13:35:20  Re: Plus/4 Expansion port... But if I got this right, the freezer fails if screen is turned off (during depacking, for example)? Posted By TLC on 2007-02-08 11:36:18  Re: Plus/4 Expansion port... I cannot inspect the IP addresses of people visiting this forum <grin> so, may I ask you who you are? As to how write cycles happen during different opcodes, it can be summarized pretty shortly: -- Opcodes that execute a single write cycle (e.g. all write operands, like sta, stx, sty, the opcodes putting a byte onto the stack like pha and php + the illegal opcode variants of these all) all do this at the very last cycle of the opcode. (E.g. the next CPU read cycle after a single CPU write cycle is predictably an opcode fetch of the next instruction). -- The majority of the opcodes that execute two consecutive write cycles are read-modify-write instructions (e.g. inc, dec, rol, ror, asl, lsr (except the implied addressing versions of these latter four) and their illegal variants. These actually write the original value back to the memory address before they'd write the modified value (this won't be functionally neccessary, it's actually a phenomenon of the simple design of the 65xx). This happens, similarly to the group above, at the last cycles of the operand. The problem is, that there's one more, 2-consecutive-write-cycle opcode, the JSR, which is different. (The JSR pushes the 2 bytes of the current PC value onto the stack _before_ finally reading the high byte of the target address). -- There's only one case when 3 consecutive write cycles are executed: the interrupt mechanism, including the execution of a BRK (push PCH, PCL and SR). This also won't happen at the last cycles of the "operand" ($fffe and $ffff are fetched after this). You can read more about these (for example) in the 64doc article by Marko Mäkelä and John West (http://www.6502.org/users/andre/petindex/local/64doc.txt). Posted By Csabo on 2007-02-08 09:28:39  Re: Plus/4 Expansion port... Ok, I know who you are now (from your IP) Posted By MasK on 2007-02-08 09:23:26  Re: Plus/4 Expansion port... I just read back now,and see,you already mentioned this mechanism..it should work,i must try this! :D I have a more complicated idea too,based on (uninterrupted) jumping instructions..but it's not perfect already,i must think about it. Some kind of code is exist,which makes the mechanism fool,it's thinking CPU is (long) jumping right now,but it's not. Posted By Csabo on 2007-02-08 09:22:51  Re: Plus/4 Expansion port... Ok, so guessing game it is. Solder? Posted By MasK on 2007-02-08 08:55:03  Re: Plus/4 Expansion port... No,i'm not BSZ/NST ..sorry You are right,this idea need some refinement. Which instruction has two write cycles? I think,only far calls are pushing two bytes onto the stack...and this should happen too,when an interrupts is served. Unfortunately this is a long chance,dma coming while a far call is executed..maybe we must wait for minutes or hours after the button is pressed..this useless on this way. What,if we are watching only two writing cycle,this should be the last two cycle of an instruction,a new fetch cycle is coming now..? Posted By TLC on 2007-02-08 06:33:11  Re: Plus/4 Expansion port... First I though, you must be my old friend BSZ/NST (deducting from the enthusiastic attitude and the fact that he's rarely (if ever) seen here amongst those that can get the principle of this hack at all )... Well, this method, unfortunately, won't work. The description would be true for interrupts, but not for DMAs. When the CPU is interrupted, the currently executed instruction is finished before the interrupt mechanism would be started (just like you described). For DMA requests (BA is pulled), this doesn't apply. The CPU would finish pending _write_ cycles (if there are any), and then stopped right on the next read cycle. The TED leaves 3 cycles for the CPU to finish executing consecutive write cycles. This is the "worst case" for 65xx series CPUs. (Some opcodes write just a single byte, read-modify-write opcodes + JSR write two in a row, the interrupt mechanism including the execution of BRK writes three). So, after the DMA had finished, the next memory fetch could be either opcode or operand fetch, but it's not predictable. (Your idea could work in some cases "accidentally", BTW. The reason is, most opcodes execute a write as the opcode's last cycle... so, in the very first cycle after a DMA, it's more likely that a memory fetch is an opcode fetch than otherwise... but not much more). Posted By Csabo on 2007-02-06 22:43:34  Re: Plus/4 Expansion port... I'm trying to guess who, but I can't. Give us a hint, won't you? Posted By MasK on 2007-02-06 18:36:33  Re: Plus/4 Expansion port... MikeD,TLC!! I have an idea about the improved freezer cartidge...I will try it on next week...but i'm sure it must work perfectly. TLC's extended freezer idea (pulling data bus low,to reach a "BRK") a very interesting trick,but have a leak...how we can know,CPU fetches an instruction right now? The short answer is more-more simpler,than we think,for first look.. We don't need a big ,complicated hardware,counting cycles,checking address and data bus..etc. There is some DMA technique in our little computer. TED "stops" the CPU when it need bus access in both half of CLK signal,asserting BA and then AEC low. Why the TED waiting some (always 4!) cycles before totally refusing bus access from CPU? Because,all members of the 65xx CPU family,can only "insert wait states" when already completely finished an instruction,and next fetch cycle is coming... Yes,this is the point!! It's very simple!! We must wait (a common edge clocked flip-flop will do for that) until TED starting,and finishing next DMA cycle. At that moment,when BA released,and CPU can "work again",it is sure,a fetch cycle is coming shortly,as CLK goes high,we can pull down the data bus!! CPU fetches a BRK immediately,jumping to an interrupt...going to read FFFE etc..from this point we can use simply "spedy like" mechanic,to catch execution in undecoded address space and do our little tricks from here:D Some good coders are maybe help us,with an improved freezer style monitor... Tedmon is good for common applications,but based on kernal,using many zero page variables....etc,etc....useless for a real freezer. There is another,"software side" problems too... For a correct,ram editing,"monitor enabled" freezer cartridge,we must use external ram,to avoid damage a single byte in the freezed code. We need the zero page,because indexed instructions and stack,so freezer code must copy it's contents (at least partially) to external ram,very-very first.. Screen data should copy too... But!! There is no way,to do that,what C64 freezer does! An externally connected SRAM never "covers" totally the internal ram! When data is written by the CPU,not the "rom decoded" external SRAM is working,but the internal dram's content changing. We can't avoid that...or maybe on a "barbaric way",brute force pulling CAS high,like c16 external ram cartridge does that. Luckily,the undecoded address space is exist..with a lot of work,we can catch our goals while using correct solutions. There is only one right way:map the external ram there(small,swapped pieces) and copy data out,trough that small window. We should do all that backwards,when freezer is exiting,and we are returning to leaved code. Posted By indi on 2007-01-27 11:38:01  Re: Plus/4 Expansion port... Im not really up on these kinds of chips just yet - I suspect it'll take me a while to catch up to everyone else (having only started this kind of thing a few months ago) Nah...pics are easy-peasy. I've been using them to build my scrolly message board, so I know they are pretty simple. my only concen is that iot won't be fast enough, and that I'll need to add a 20Mhz crystal which would lose a couple of IO pins. Posted By Bionic on 2007-01-26 16:36:26  Re: Plus/4 Expansion port... MikeD: I just used some pliers to break the connectors off. They break easily along the row of solder holes. Nice blog btw You should get some programmable logic chips (CPLD). They would make your life much easier. Address decoding with a PIC sounds like trouble. Posted By indi on 2007-01-12 04:07:54  Re: Plus/4 Expansion port... Yeah, I got a stack of these too and then had to rush out and buy a little hack-saw! After I did my LCD addon ( you can see it here....http://dailly.blogspot.com ) I decided that the next thing I should do is build a board that I can take wires from the 8bitbaby that then plug right into a Breadboard to make prototyping easier. Would have made life a lot easier..... Posted By Bionic on 2007-01-11 15:30:19  Re: Plus/4 Expansion port... Now I got some of these nice boards: www.8bitbaby.de You have to remove two of the connectors to fit it into a Plus/4 expansion port, but it is still a very nice way to build Plus/4 HW. I may try some freezer ideas next week, have to find some parts first.. Posted By TLC on 2007-01-09 17:52:36  Re: Plus/4 Expansion port... Christian: Jeese :D... (I'm actually pretty surprised about the presence of this card... ). At first I thought this would be easy, but after spending some minutes with checking the images, I'm more and more confused... Posted By Bionic on 2007-01-09 17:48:57  Re: Plus/4 Expansion port... Solder: Looking at the images it seems that only A15-A0, D7-D0,R/W,RAS,CAS,Phi2 and MUX are connected. So there is no trickery with cardridge select etc. From what I can make out the CAS line is connected to the transistor. So it appears that the CAS line is actively driven high to avoid accessing the internal DRAM. If course that may work, but you need quite some current. I guess that is why a transistor is used. Not a very nice design. I would be afraid of damaging the TED. Posted By indi on 2007-01-09 16:26:03  Re: Plus/4 Expansion port... The important part is the proper monitor - this means reset won't work as you lose all the registers and can't restart. But, like the freezer, I don't think it too much to specify that it needs interrupts on....or hit a BRK or something. Once you have a cart that can do this then adding more tools should be easy enough - like the retro replay gets. adding a SID+MMC to it would be great too! :D Posted By Solder on 2007-01-09 15:53:44  Re: Plus/4 Expansion port... Hi Mike, if this tool is available for C64 it should not be difficult to convert to a plus/4-version. If it's enough to stop the plus/4 with Reset+RUN/STOP and then start this tool at external module or this could be done automatic because the modules are started from kernel at every reset. If I understand you right, you need an improved monitor with help to find font sets, graphic data or music in the memory? Posted By Solder on 2007-01-09 15:41:59  Re: Plus/4 Expansion port... Levente, Tim: How works the external +16k RAM Expansion??? [ link ] Solder Posted By indi on 2007-01-09 14:06:53  Re: Plus/4 Expansion port... I don't think a freezer is needed, but a monitor/gfx/sound ripper/tool would be cool. I';d love to press a button and be able to go into a monitor like on the C64. Freezing I could live without really.....handy....but not vital. Posted By Solder on 2007-01-09 13:30:13  Re: Plus/4 Expansion port... I've now checked my version of schematic of reverse engeneering. My or the freezer from Jerzy Sobola modul must be a remake (I think, we had ours from FraggleSoft, another hardware man at this time - he made the 1551-add on for using with warpdos, anyone remember? ). The function is the same, but some chips are replaced by other: There is no LS09, just 7400 and 7406. All chips were standard-TTL. And I remember that there was a mysterious 7274 or 6474 (I'm not sure). But from function of it, this was the 7474. Is a freezer really needed for plus/4 (maybe in combination with SID-card?) There is this fine freezer on YAPE. Isn't it enough? The freezer only works with IRQ, but isn't it enough? The most games uses IRQ (Rastertime, no SEI, you would see this), so it should work. Maybe you can't freeze some demos, but I think this isn't important. Posted By TLC on 2007-01-09 10:27:19  Re: Plus/4 Expansion port... Whilst all Commodore circuits are NMOS, I'm not that concerned about the DRAMs... still, I'm almost absolutely sure that this "forcing a 0 byte onto the databus while the DRAM bank is active"-thing should work. Posted By TLC on 2007-01-09 10:21:25  Re: Plus/4 Expansion port... Solder: I don't actually know the MMU in the TED well... I just followed the line of the schematics (it might be slightly badly reverse engineered, still, it looks very likely that it's possible to fool the MMU logics with a simple trick like that assertion of A9... I haven't actually been aware of this phenomenon previously). Banking in the EPROM immediately looked still suspicious to me (for an EPROM to work, some time is needed for things to settle, at least if the CS' line is used for selecting the chip; but thinking it over again, it'd be enough if the CS' of the EPROM was controlled by something like the A15, continously (which doesn't harm anything as long as OE is not asserted), and "banking in" the thing went by asserting OE' (which is quick, and has no dependency on any other conditions). Posted By TLC on 2007-01-09 09:50:26  Re: Plus/4 Expansion port... The JSR pushes two bytes onto the stack... that's two consecutive write cycle... Posted By Bionic on 2007-01-09 08:01:32  Re: Plus/4 Expansion port... The timing in the Plus/4 is fairly conservative. Snooping for $FFFX an the address bus and then forcing A9 low should work. You have a couple of 100ns for that. Note that the address bus is active before the data bus so you have plenty of margin to avoid a collision. If you don't wait for an IRQ before the snooping you may also trigger on a normal memory read. (Which is fairly unlikely though..) I like the idea with the BRK, because it would also work without the IRQ being active. Forcing $00 into the databus should be possible in the Plus/4 since it is NMOS only. But I think it is quite difficult to detect actual opcode reads. What if an JSR is executed? Posted By Solder on 2007-01-09 07:26:29  Re: Plus/4 Expansion port... Hi TLC, hmmm, how does the MMU in TED works? Is it a static decoder? That means, if $fffe is activated by the CPU and A9 is pulled down (4 ns) TED disables immidiately CAS or CS1? Then it would be enough to check for $fffe and if true then pull down A9. There is enough time from changing the address to read the datas by CPU. Solder Posted By TLC on 2007-01-09 06:27:19  Re: Plus/4 Expansion port... Another addition, which just popped up in my mind... in the hw-IRQ approach, a currently executed interrupt-mechanism could be sensed by just counting consecutive cpu write cycles... If 3 consecutive write cycles are counted, the EPROM / A9 trick could be asserted, as the next memory fetch by the CPU _will_ be done from the IRQ vector. Posted By TLC on 2007-01-09 06:16:26  Re: Plus/4 Expansion port... I've been playing with ideas about this freezer-thing for a while... For an approach where hw IRQ' is exploited (where it's important that the currently running software uses interrupts), the current problem is that we don't know, exactly when would the execution of the interrupt request finally taken into account. Until the mechanism would start, we can't safely pull A9 low to hijack the read from $fffe/$ffff. But... what if we modified this method a little bit?... What if we didn't care about the IRQ line, but rather based the start of the freezing on the CPU reading the IRQ' vector?... At first, sensing the addressing of $fffe by the CPU is a good sign of the IRQ' mechanism to be currently executed. By hijacking the IRQ' vector at this minute, the freezer could be made perfect. ...Or maybe not. Maybe, it's too late at this minute, to turn on the external ROM + asserting A9, for the CPU to read from $fdfe. ...What if we waited until a read was executed from $ffff (this alone, signs that an IRQ is currently being started to be served), then -- for the next CPU cycle -- forced all databus bits to 0, and _then_ turned the ROM / A9 trick on. This would result in executing a BRK, effectively starting yet another IRQ' process, but now we would know what is going on and could have the IRQ' vector hijacked way before it's actually read. (I'm not sure if all this is actually neccessary). A slightly more complicated approach could be not to rely upon hardware interrupts at all, but force executing a BRK instead. Putting something to the databus, regardless to the value given by the motherboard RAM is possible somehow (those memory expansions for the C16 work exactly like this). The hard part is to figure out, if a particular fetch from memory would be an instruction byte fetch or not. A simple work-around could be based on the fact that simple write opcodes (those with only one single write cycle ) would always execute a memory write as their last cycle; thus, the next cycle would always be an opcode fetch (which could be hijacked by forcing a BRK, ie. 0). After successfully completing this, the known ROM / A9 trick could be activated... the fact that executing a BRK doesn't depend on the I bit would make sure that the interrupt request mechanism is executed immediately (ie. it's actually safe to pull A9 low by then). It could also freeze programs disabling interrupts completely or enabling no hardware interrupt sources. Posted By Solder on 2007-01-09 04:42:29  Re: Plus/4 Expansion port... I have taken the circuit from the freezer independent from your schematic in the early 90th as I had a short look to this (it was at a nice visit at LinTronic - another hardware man in Germany at this time...). Also we had read out the EPROM. I will compare the schematics when I'm at home in the evening... Solder Posted By TLC on 2007-01-08 19:22:11  Re: Plus/4 Expansion port... I don't know... but all in all, it has just given you an inspiration for a more enhanced implementation of a freezer, which is nice... Posted By Bionic on 2007-01-08 17:47:01  Re: Plus/4 Expansion port... If the I flag in the CPU is set - bad luck. It would not be an issue if only $FFFE/$FFFF (not xC/xD as I stated previously) were hijacked. The circuit misses some gates for that. All that would be required is an AND gate for A13/A14 and proper programming of the EEPROM (fill unsued space with $FF). Maybe another error in the schematic? Posted By TLC on 2007-01-08 17:36:27  Re: Plus/4 Expansion port... That's the other thing I asked myself amongst the question of A9... Also, what if interrupts in the CPU are disabled (SEI)?... A9 would still be asserted... The ROM would still be paged in... Posted By Bionic on 2007-01-08 17:16:21  Re: Plus/4 Expansion port... I just wonder what happens if program code from RAM above $8000 is executed while the irq is asserted? Would probably screw up the program state. Did this freezer cardridge word with more than 16k of memory? Posted By Bionic on 2007-01-08 17:08:39  Re: Plus/4 Expansion port... My guess is that the flip flops inputs are mixed up. IRQ does probably go to the clk input and the switch to D. Posted By TLC on 2007-01-08 17:00:01  Re: Plus/4 Expansion port... Mike: I've checked the images... I'm actually surprised that those can be _that_ simple... Bionic: well, good theory... Actually, if the card really works like that, then it must have been reverse-engineered inaccurately... or whatever... according to that sch, A9 would be asserted low as soon as a high (inactive) IRQ' state is latched (amongst other conditions like AEC is high and R/W' is high); the circuit won't wait for IRQ' to drop (thus it could disturb a running code before finally catching an IRQ'...). Neat finding, anyway. The algorithm should certainly be possible (as far as I can see) to implement in a new design. Posted By Bionic on 2007-01-08 16:35:51  Re: Plus/4 Expansion port... Also, on the C64 you can force an NMI. On the plus/4 you can simply disable that freezer by not using interrupts. Posted By Bionic on 2007-01-08 16:26:02  Re: Plus/4 Expansion port... Miked: Actually the C64 has some additional input in the expansion port (GAME) which can be used to force external ROMS into the address space. Things are quite different there, maybe even easier. Posted By Bionic on 2007-01-08 16:25:05  Re: Plus/4 Expansion port... Actually the circuit does work. It seem to be a pretty neat trick. Without checking the circuit in detail, here is what I believe it does: -When the button is pressed the flip flop is set. -When an Irq is asserted (IRQ=LOW) and the flip flop is set it activates OE and pulls A9 low. -The CPU tries to fetch the IRQ address from $FFFC/$FFFD, but since A9=0 it effectively fetches from $FDFC/$FDFD (unmapped memory space!). -This sets A15=high, which will active CE of the eprom, and hence map it to the unmapped space. -The fetched IRQ adress points to somewhere in the eprom and a user program is executed, which will *Save registers, TED state, Activate module one (C1L=Low) -C1L=Low resets the flip flow. -Freezer program is being executed from the eprom. Really neat, great addition to the virtual SID-Card Posted By indi on 2007-01-08 16:04:43  Re: Plus/4 Expansion port... commodore16.com has a couple of bare C16 RAM packs.... http://www.commodore16.com/images/c16_ram_expnew1.jpg http://www.commodore16.com/images/c16_ram_expnew2.jpg Although the lower side isn't visinvisible, I guess you could buy one and look it over if you really wanted to The freezer is one of the reasons I was asking about what lines could be played with... I did think that if you could force the external lines and bank a ROM in, you should be able to hijack the IRQ vector with a "special" ROM, then take it from there. The C64 was able to freeze using a cart and then reload without it, so the Plus4 should be able to as well. Posted By Bionic on 2007-01-08 15:56:45  Re: Plus/4 Expansion port... A working freezer module without the GAME input? That is great. Another feature to add to the virtual CPLD based SID-Card. I have to check the schematics. Posted By TLC on 2007-01-08 15:17:48  Re: Plus/4 Expansion port... Mike: yeah, it looks like (but not much of us have ever heard about it as I suppose ). Posted By TLC on 2007-01-08 15:07:17  Re: Plus/4 Expansion port... Hi Christian! Well... I do have a 64K memory expansion module (like that) somewhere, but never checked it closely (I thought I'd need to break the case open just to take a close look at the board... which I didn't want). So I haven't even known that they're just that plain simple inside. As for the freezer module... I was lucky enough to browse the ex-Funet CBM archive (now hosted at zimmers.net) someday and stumbled upon this: http://www.zimmers.net/anonftp/pub/cbm/schematics/cartridges/plus4/index.html . Jerzy Sobola has reverse engineered the cartridge and drew a schematic / exported the EPROM dump. I checked the sch, but for me it's a little bit confusing. It's clear that the Eprom can be "seen" at Cartridge 1 low, regardless to other conditions. This makes it able to "boot". There's a circuit, that would also assert this chip regardless to the RAM/ROM banking settings and C1low, as soon as 1.) the pushbutton is pressed, 2.) IRQ is high, 3.) AEC is high, 4.) A15 is high. Upon 1.), 2.) and 3.), plus 4.) R/W' is high, A9 of the address bus would also be forced to low. ...I just can't complete the story. What is all this hassle about?... I can understand pieces, but not the whole thing. For example, pulling the address line (which is fully legal, as the circuit pulls it down by an OC output) would be suitable (mostly) for hijacking a currently running code. Also, forcing in the EPROM might be suitable to do some "bootstrapping", then initializing the RAM/ROM setting and finally bank in C1low. ...It's just not fully logical. For example, why messing with A9 at all?... Also, it could be possible to freeze something using this method, but not restarting it, as far as I'm concerned. ...Should be the conclusion, that the sch is not fully precise?... Posted By indi on 2007-01-08 15:04:39  Re: Plus/4 Expansion port... Someone actually mananed to do a freezer module? That would have been cool... Posted By Solder on 2007-01-08 12:35:11  Re: Plus/4 Expansion port... Hi TLC, yes, it's a big mystery. I have seen this expansion cards and they have just the 2 multiplexers and 2 RAM-chips on pcb. Maybe it's enough that the RAMs are faster than the internal? But I have also seen instructions, that, if the expansion doesn't work you have to open the C16 and cut 2(?) pins... Is there anybody who know how the plus/4-freezer module works? I have seen this years ago and it worked. Solder Posted By TLC on 2007-01-08 06:23:38  Re: Plus/4 Expansion port... The C16 has only 16k of RAM installed, but unfortunately, this won't solve this mistery... The address decoding in the Plus/4 is incomplete. If you access RAM above $4000, the internal ram chips would still get selected and "talk" (the read value just repeats for each 16k pages). That's the problem... Posted By indi on 2007-01-08 01:16:56  Re: Plus/4 Expansion port... As far as I can tell, there would be no problem with an external 64K expansion for the C16 as theres no RAM there in the 1st place. This means it'll never be in conflict with any DATA being sent from the external bus. You don't need to use the RAS/CAS lines either, as you can just decode the address lines yourself. The only problem with a +4 memory expansion is that yes, DATA would be send from the internal ram and external ram at the same time....this wouldn't happen with a C16 since its not a 64K expansion, but 48K one... and you never get a request for memory that overlaps. .....I think.... Posted By TLC on 2007-01-07 19:04:02  Re: Plus/4 Expansion port... On a related note... Christian, do you happen to know how did those external 64K dram expansions for the C16/C116 really work?... This is a longtime hmmm... "mystery" for me. As far as I know, there's no real ram "paging" in the computer. When ram is addressed, the ras/mux/cas lines would be asserted, effectively selecting the dram chips _of the motherboard_. Even if something else -- say, dram chips on an external card -- are also selected, these (the internal and the external chips) would "talk" at the same time. Then, how could still those external memory expansions work? I must be missing something... :-/ Posted By indi on 2007-01-07 13:47:08  Re: Plus/4 Expansion port... Not sure....but if you could force certain lines then you might be able to force in a ROM and overwrite vectors etc... I don't know. One thing I have been thinking about is using the ROM lines and putting RAM there. That way although the RAM under the ROM would just be filled with rubbish, the MMU that deals with the ROM would allow you to have external RAM for reads - which is the hard part. The address+RW lines would allow you to write to the RAM easily enough. Then you could introduce a memory location and have the RAM banked in 8 or 16K regions. Its a bit of a hack, but should allow you to have proper external RAM on a cartridge. So...it would work something like this.... Disable interrupts. Set External RAM bank to 0 Set ROM enable Enable the external ROM's by writing to FDDx (whatever value works.. %1010 I think) $8000->$BFFF is now pagable RAM while $c000->$ffff is a single fixed page. You then read and write to/from it as normal, and using the ExternalRAM bank register(s) to swap them.... If you ever disabled the ROM's then the RAM from $8000->$ffff would be rubbish - just random writes, but that doesn't matter as you never have to disable it - even if you don't BANK it. Having 4,8 or 16K banks would be fine...4K would allow the most flexibility, but 16K would be by far the easiest, and only require a single byte register. Theres obviously some limits you'd have to handle... IO space, and $FC00 would always be bank 0 etc... aside from that - I think it should work.. What do you think? RAM that pretends to be ROM....? Posted By Solder on 2007-01-07 12:34:46  Re: Plus/4 Expansion port... >Does this mean some lines like the ROM select can be altered via the port? Mike, what do you want to do? CS0, CS1 and CAS are generated by TED as MMU for read access. It depends from actual adress from the CPU and from $ff3e (ROM access) or $ff3f (RAM access). ROM access low: CS0 ($8000-bfff) , ROM access high: CS1 ($c000-fcff, $ff40-ffff) or RAM access: CAS ($8000-fcff, $ff40-ffff) is generated. For write access always CAS is generated except I/O-area and TED-registers. That means that $ff3e or $ff3f isn't important for writing. Datas are always written to the RAM, also if $ff3e is activated. CS0 and CS1 are divided to other signals to accessing the ROM-banks, but there is one exception: from $fc00 to $fcff always bank 0, high (Kernel) is activated. For access to the font-memory which the TED needs there is an other way (in the TED-registers) to control the access via CS0, CS1 and CAS. Solder. Posted By indi on 2007-01-06 17:41:18  Re: Plus/4 Expansion port... Damn...thats what I thought...but I was ever hopeful. Posted By Solder on 2007-01-06 06:28:27  Re: Plus/4 Expansion port... Outputs: A0-A15, CS0, CS1, RAS, CAS, MUX, Phi2, Phi0, BA, AEC, C1High, C1Low, C2High, C2Low, BReset, R/W Inputs: Ext. Audio, IRQ In/Out: D0-D7 Solder Posted By indi on 2007-01-06 06:06:40  Re: Plus/4 Expansion port... I have a quick question...After reading through this some of the pins marked as "outputs" are obviously not JUST outputs. The data lines for example MUST allow input as well since you can plug cartrideges in the back and it has to get the data back from there. So what else isn't "just" an output? Is it only the lines marked "output only"? Does this mean some lines like the ROM select can be altered via the port? Posted By indi on 2006-11-26 04:40:46  Re: Plus/4 Expansion port... Yep - that'll do Posted By Sidius on 2006-11-25 09:45:11  Re: Plus/4 Expansion port... Do you mean something like this ? http://solder.dyndns.info/pub/files/commodore/plus4/hardware/Service_Manual/22_Expansion_Bus.pdf Posted By indi on 2006-11-25 06:32:59  Plus/4 Expansion port... Is there a page like this one "http://members.aol.com/c64128/eport.htm" for the plus/4 anywhere? If not can anyone knock one up? Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon