LGB
Newbie
Posts: 9
|
Post by LGB on Feb 2, 2011 12:08:34 GMT -5
Hi, I have the problem with DTV that it does not have expansion port, so besides the usual (IEC bus, user port, etc) connectivity (after some modding) it's not possible to introduce new features, which requires more "raw" access to the bus. For example I am really interested in to have some network solution for the DTV, much like TFE and RR-Net for the C64. For sure, other possibilities can be mentioned too. Note, I do not expect C64 extension port compatibility just "something similar.
This has come into my mind: I can replace the flash chip somehow, and - let's say - I can reuse some amount of address space dedicated to the flash for my own purposes. Sure, I will lose some flash capacity, but with ethernet, I can load something from the net, I don't need so much flash space then :) It's much better than using address space from the SDRAM, since RAM is more "precious", also SDRAM has more complicated RAS/CAS/etc addressing, while flash may not (though I don't know if it's true or not). However I am far from being expert in this area, that's why I am asking here about the opinions on my idea.
This way I can have some memory mapped I/O in the flash area, I can even use DTV's DMA to transfer data. As I've told, I don't expect that it will be C64 expansion port compatible, but it's not even a goal.
|
|
|
Post by tlr on Feb 2, 2011 15:23:41 GMT -5
There is one unused address bit so you have 2 MByte of free flash space to pick from.
|
|
LGB
Newbie
Posts: 9
|
Post by LGB on Feb 2, 2011 17:44:59 GMT -5
There is one unused address bit so you have 2 MByte of free flash space to pick from. Thx for your answer! Hmmm. It's true that flash and SDRAM has separate bus (also in the sense that they are different address spaces, address $10000 for example means the flash directory start in flash, and simply the start of second 64K in the SDRAM), and different 256 segments can be mapped, which in case of different address spaces it means (in theory) 4M for flash, and 4M for RAM. Still, I am not sure if the "missing bit" really exists on the DTV PCB. But anyway my question is more about the possibility: I am really not sure that it's so "easy" to just solder some wires to the pins of the flash and it would work, or there is some fundamental issues with my idea. I thought about flash, since I just have the hope that address/data signals are there (without the complexity of SDRAM for example), which can be used then.
|
|
|
Post by tlr on Feb 3, 2011 14:46:37 GMT -5
There is one unused address bit so you have 2 MByte of free flash space to pick from. Thx for your answer! Hmmm. It's true that flash and SDRAM has separate bus (also in the sense that they are different address spaces, address $10000 for example means the flash directory start in flash, and simply the start of second 64K in the SDRAM), and different 256 segments can be mapped, which in case of different address spaces it means (in theory) 4M for flash, and 4M for RAM. Still, I am not sure if the "missing bit" really exists on the DTV PCB. But anyway my question is more about the possibility: I am really not sure that it's so "easy" to just solder some wires to the pins of the flash and it would work, or there is some fundamental issues with my idea. I thought about flash, since I just have the hope that address/data signals are there (without the complexity of SDRAM for example), which can be used then. It should be possible to solder a bunch of wires to the data, address and control lines at the flash chip (+ A21) to do what you are after. The bus timing is explained here: bus timing (from the DTV Programming guide) (there are some discrepancies in the actual implementation IIRC) A21 is available on the board, see here: C64DTV solder points
|
|
|
Post by 1570 on Feb 4, 2011 4:52:58 GMT -5
This way I can have some memory mapped I/O in the flash area, I can even use DTV's DMA to transfer data. Why not just using the userport? It is relatively easy to wire, and AFAIR you can also use DMA: Attach some microcontroller to it that writes a new byte every cycle, then do DMA with parameters [source: user port data, sourceStep: 0, dest: RAM, destStep: 1].
|
|
LGB
Newbie
Posts: 9
|
Post by LGB on Feb 4, 2011 7:10:18 GMT -5
Why not just using the userport? It is relatively easy to wire, and AFAIR you can also use DMA: Attach some microcontroller to it that writes a new byte every cycle, then do DMA with parameters [source: user port data, sourceStep: 0, dest: RAM, destStep: 1]. Yes, that was my original thought (I also asked on 1541U forum, that it would be cool to be able to use 1541U somehow through the user port, and at least some functionality of it - not all - can be used with DTV too, not only the standalone mode, so the IEC bus), maybe it's much more easier and needs less messing with the DTV board :) However it's not as flexible, for example some "random access" like theory needs to output the address first then I can read some data set on the uC with the set address output before. Some direct bus connection is cool, since in case of an ethernet buffer for example, I may check many bytes before I decide to copy memory areas. Though you're right maybe this point of mine is to weak and simply it does not worth to think about my idea to just save some complexity about the addressing when the solution itself (for modding) is much more complicated. Hmm. What I am really unsure about: let's say I want to read data through the user port. I can set up DMA to do this, but how I can keep the uC in sync which is connected to the user port? I mean, how the uC knows that DMA has read a byte, and a new one should be transmitted through the user port? Now just one question comes into my mind: is it possible to generate an IRQ? Sure, it would be better than polling eg. my ethernet stuff all the time (though it would be a question with my idea too, btw, it's not the "user port solution" problem only) And since you seems to be much more experienced about the topic: what kind of kernal do I need to flash which contain some hard coded parameters instead of polling the user port (which is done by the original DTV kernal)? Since as far as I know, to sue the user port for my purposed, I need to "free it up" from the feature first.
|
|
LGB
Newbie
Posts: 9
|
Post by LGB on Feb 4, 2011 7:40:30 GMT -5
Thanks, I haven't noticed A21 before ...
|
|
|
Post by 1570 on Feb 5, 2011 7:51:49 GMT -5
What I am really unsure about: let's say I want to read data through the user port. I can set up DMA to do this, but how I can keep the uC in sync which is connected to the user port? You can do the same that pretty much all fastloaders do: Synchronize every now and then in software (wait for some arbitrary sync signal), then transmit timing-based. Since both the DTV and the attached hardware do not do anything that introduces jitter, this works pretty well. AFAIR there are fastloaders around for the C64 that sync only every few milliseconds. Just study some fastloader code as the problem there is pretty much the same. Possibly, I'm not sure the IRQ/NMI lines in the DTV are available for write though. In any case, if you trigger one interrupt per byte, this will be horribly slow. You need to patch the DTV kernal with kernalpatcher in order to hardcode video settings which are otherwise read from the userport resistor configuration. picobay.com/dtv_wiki/index.php?title=Kernalpatcher
|
|
LGB
Newbie
Posts: 9
|
Post by LGB on Feb 5, 2011 17:36:16 GMT -5
You can do the same that pretty much all fastloaders do: Synchronize every now and then in software (wait for some arbitrary sync signal), then transmit timing-based. Since both the DTV and the attached hardware do not do anything that introduces jitter, this works pretty well. AFAIR there are fastloaders around for the C64 that sync only every few milliseconds. Just study some fastloader code as the problem there is pretty much the same. Hmm that is what not so true in my case at least ... I would like to use many things maybe using Blitter or just having video mode which involves color fetches, it messes the sync up. I had an experiment to play digi with using DMA only: cubed-borka.blogspot.com/2011/02/audio-sample-playback-on-c64dtv-without.html Even just having color fetch by VIC makes the sound distorted and ugly, which clearly notices that DMA is "not stable" when other thing steal cycles in the DTV too. Some fastloader in a demo can be cool, but if you want a versatile solution like writing a multitasking OS (which is my so big and far idea ...) then you can't say you have "full time" to do something. That is exactly the reason I gave up my plans with user port and I started to think about using bus signals at the flash instead: then I don't need any sync, I can clearly know when I read/write a byte.Sure, but I did not mean this. I meant that I don't like even with RR-Net or TFE that you must poll if it received package. That is not so nice in my opinion, what I would like that my DTV ethernet solution can notice DTV that there is something to receive. Then of course DMA can be used to transfer the received packet, not byte-by-byte per IRQ, but at once. So it is another issue, sorry if I was misunderstandable here.
|
|
|
Post by 1570 on Feb 6, 2011 8:47:20 GMT -5
I would like to use many things maybe using Blitter or just having video mode which involves color fetches, it messes the sync up. You can disable badline emulation on the DTV (see $D03C).
|
|
LGB
Newbie
Posts: 9
|
Post by LGB on Feb 7, 2011 4:45:14 GMT -5
I would like to use many things maybe using Blitter or just having video mode which involves color fetches, it messes the sync up. You can disable badline emulation on the DTV (see $D03C). Ok, thanks, I will try that, but I am still not sure color fetch won't steal cycles if I disable badline emulation at least. And please note, that it's not the major point of my "problem", I still feel somehow, that it's much better that I can read my "I/O space" freely byte-by-byte by the CPU if I need that, or using DMA, if I need to transfer more data etc, without the need to worry about the sync issue (and I can even use blitter which would affect the timing for example). So for me, it sounds much more "cool" to be able to read/write I/O space "freely" as a memory mapped I/O rather than using only DMA (with strict rules on the timing), but I have to admit that I have maybe "too distant" goals with having ideas like these, still it's easier to implement something connected to the user port, than try to connect to the bus can be accessed at the pins of the flash IC. I always felt that design of Enterprise-128 computer is very cool from this point of view: it's a Z80 based computer but even the system address bus on the PCB is already 22 bit wide (with the help of a very similar memory mapping method as DTV has, but not built-in the CPU, also not separated address spaces), and even system components on the pcb has decoded addresses from the 22 bit address bus. So it's very easy to put extra memory mapped I/O, or anything without building extra memory decoding and needing to worry about the "conflict" of just two and very small I/O areas like the original C64 has "built-in". My original plan with DTV is this: to have a quite large, decoded memory area at the area of flash, where I can put many things then and can be accessed by the CPU/DMA without the need of "strict" timing or any special care. For sure, it's not the most simple method to "expand" the DTV, user port method is still simplier.
|
|