tag:blogger.com,1999:blog-4017745189504803687.post5142468926367275342..comments2024-02-28T07:29:15.484+10:30Comments on Making a C64/C65 compatible computer: More work on proportional fontsPaul Gardner-Stephenhttp://www.blogger.com/profile/10150903760695355706noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-4017745189504803687.post-69234608277356658152014-11-06T13:54:27.405+10:302014-11-06T13:54:27.405+10:30If I had to describe the mental shift from assembl...If I had to describe the mental shift from assembly language to VHDL, it is simply this: 1. Everything happens at once. 2. Your job is to calculate the signals to tell everything what it is doing (or not doing) during the next cycle. Basically apply your understanding of how a CPU works, and make your own functional units and the control logic to tell them when to do stuff. As for particular material to learn, I think just google for tutorials or start looking at simple projects. Start with the blinking led type things, and then work your way up. If you can make a simple state machine in VHDL, you have learned the single most important skill.<br /><br />Paul.Paul Gardner-Stephenhttps://www.blogger.com/profile/10150903760695355706noreply@blogger.comtag:blogger.com,1999:blog-4017745189504803687.post-10368620438368660242014-11-05T21:36:37.246+10:302014-11-05T21:36:37.246+10:30Ah sorry, too much comments :) About about the VHD...Ah sorry, too much comments :) About about the VHDL: though I have a dream to start FPGA etc projects, I failed all the times when I tried to learn Verilog and/or VHDL somehow it's just alien for me regardless my willpower to learn it. I can code in many languages (including assembly for multiple CPUs, and higher level languages too), HDLs are so different as you know it too :) Also notions like RTL level etc, just confuses me, I just want to describe the logic and that's all, I don't want to deal with these complex topics, but it seems it is not the way it works :( But you, as an experienced person in this topic may be able to suggest some good resources for a guy like me (ie who has not so much knowledge on the topic, and don't want to dig in the deep field just create projects as simple as possible and of course to learn some HDL let it be Verilog or VHDL) to learn ... But this should be sent in a mail or such not as a comment on a totally different topic, I guess :) Sorry about that.LGBhttps://www.blogger.com/profile/04820526370036466739noreply@blogger.comtag:blogger.com,1999:blog-4017745189504803687.post-30205230508971519402014-11-05T21:18:15.488+10:302014-11-05T21:18:15.488+10:30By the way, something similar is implemented with ...By the way, something similar is implemented with the almost unknown Commodore LCD (I dunno about C128, even if Bil Herd told me that C128's MMU is a thing created after the LCD's learning lessons from it) machine: though it has fixed mapping for the top area of the memory, it can save the MMU mode and restore the saved one. Of course it's still not "perfect" as it forces you to have the top of the memory always mapped in, which would be nice not to be compulsory :)LGBhttps://www.blogger.com/profile/04820526370036466739noreply@blogger.comtag:blogger.com,1999:blog-4017745189504803687.post-59561759392241109402014-11-05T20:46:25.872+10:302014-11-05T20:46:25.872+10:30Yes, I agree that mapping to 0 is a bit strange, b...Yes, I agree that mapping to 0 is a bit strange, but that's what we have to work with. As for IRQs etc triggering outside of the current 64KB, while the C65 doesn't do that, I have already added a simple hypervisor facility to the C65GS that saves all CPU state -- including memory map -- and sets up a specific memory map and jumps to a vector there. This also has the advantage that entry and exit take one cycle, even though about 20 bytes of information gets saved.<br />Paul.Paul Gardner-Stephenhttps://www.blogger.com/profile/10150903760695355706noreply@blogger.comtag:blogger.com,1999:blog-4017745189504803687.post-6039785293109170182014-11-05T20:31:35.825+10:302014-11-05T20:31:35.825+10:30That's exactly what bothers me: the mapped not...That's exactly what bothers me: the mapped not mapped, it does not make any sense in my opinion: etc mapping something (in a more "sane" banking method) from 0 is exactly the same as "not mapped", I never understand why it is needed to make difference (it is also a part of my opinion that banking/paging on Commodore machines are overcomplicated, a much more simple way is not provided like what I've described for the C64DTV as an example). About the IRQ: what I like about 65816 that it can serve IRQ (and other interrupts) even if the vector is not seen by the CPU currently. Ok, 65816 is different theory. Thus some kind of "IRQ mapping" would be great: to use a certain mapping automatically if IRQ comes, even if it's not mapped currently. This is great that you can use all of the CPU 64K address space and no need for worrying about IRQ (or RESET, or BRK for eg "syscall" like instruction in an advanced OS). Of course then, there should be a way to backup/restore mapping automatically ........LGBhttps://www.blogger.com/profile/04820526370036466739noreply@blogger.comtag:blogger.com,1999:blog-4017745189504803687.post-66312612586946557322014-11-05T11:36:32.164+10:302014-11-05T11:36:32.164+10:30Sounds nice re DTV OS. You are certainly welcome ...Sounds nice re DTV OS. You are certainly welcome to work on something similar for the C65GS. Memory is banked mostly the C65 way, which means that you can select whether each 8KB block is banked, and separately choose the offset for banking for the lower and upper 32KB halves. I agree that this is a rather odd arrangement that Commodore came up with, but it works fairly well, especially since you have a 48MHz DMA controller to pull memory in from elsewhere when needed. There is probably some scope to add some other banking magic, but I want to keep it to a minimum. The only addition to the C65 banking regime that I have made is to add an extra 8 bits of address to the top, taking the address space from 1MB to 256MB. This is also controlled with the MAP instruction using some special values. One advantage to 8KB windows is that it is easier to keep your IRQ routine always mapped, without compromising too badly.<br /><br />Keep the thoughts coming!Paul Gardner-Stephenhttps://www.blogger.com/profile/10150903760695355706noreply@blogger.comtag:blogger.com,1999:blog-4017745189504803687.post-63442204519288073412014-11-05T11:32:06.922+10:302014-11-05T11:32:06.922+10:30Hello,
You are quite right about the lack of docum...Hello,<br />You are quite right about the lack of documentation at the moment. Apart from the VHDL source code, which I concede is a bit opaque for most, someone has just started working on exactly this. Join the C65GS developers Google group, and you will be able to get the current version, and point out areas that lack documentation. Hopefully we can make the generation of the documentation collaborative. I'll respond to memory mapping etc in a moment.<br />Paul Gardner-Stephenhttps://www.blogger.com/profile/10150903760695355706noreply@blogger.comtag:blogger.com,1999:blog-4017745189504803687.post-2275998017460509802014-11-05T11:30:25.903+10:302014-11-05T11:30:25.903+10:30Hi Daniel, I haven't seen the message yet, but...Hi Daniel, I haven't seen the message yet, but will look for it. Certainly happy to discuss it on the list.Paul Gardner-Stephenhttps://www.blogger.com/profile/10150903760695355706noreply@blogger.comtag:blogger.com,1999:blog-4017745189504803687.post-35530445713980570642014-11-05T11:29:02.301+10:302014-11-05T11:29:02.301+10:30Paul, I am very concerned about the rationality of...Paul, I am very concerned about the rationality of implementing the proportional font functionality like this. I have sent you an e-mail because the post was apparently too long for me to send it here. If at all possible, could you please discuss on the group board?<br /><br />Thanks.Anonymoushttps://www.blogger.com/profile/04831681461356153688noreply@blogger.comtag:blogger.com,1999:blog-4017745189504803687.post-54085877370001913212014-11-04T22:39:24.660+10:302014-11-04T22:39:24.660+10:30OMG :) Your project is really interesting and hmm ...OMG :) Your project is really interesting and hmm complex :) Do you have any "table of contents" like document? I mean, it's just too hard to collect information by always digging in every posts from you to try to form the "big picture" in my brain. Thinks like a TOC, documents about the current features, registers etc can be useful. Sorry I don't want to disturb you in your work (because it's really interesting), just I am wonder, if you have those, or want to do those, etc. A bit another topic: since I've started to write an OS for Commodore 64 DTV (using its great abilities like 256 colour mode, blitter, DMA ...) I wonder if I can code later for C65GS as well maybe! However for example I am not sure how memory is banked, the regular "C65" way, or is there some kind of extra? Since personally I think, memory banking of C65 is quite hmm "odd" compared to the nice solution DTV (and also some other even not Commodore machines) has, ie: CPU sees 64K, divided into four 16K long segments. The main memory is also segmented like this way. You can simply tell that in any of the CPU's "windows" you can see any of the memory segments. So simple, but somehow Commodore always made the banking quite limited or even overcomplicated. In my opinion only, I mean :) Of course the ideal solution would be something like 65816 without any segments which eg would solve the "IRQ got while we are paged out the memory from there" and similar problems. Ok, I am just thinking here.LGBhttps://www.blogger.com/profile/04820526370036466739noreply@blogger.com