EtchedPixels

Members
  • Content count

    62
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by EtchedPixels

  1. EtchedPixels

    socz80: A Z80 retro microcomputer for the Papilio Pro

    If you look at the fork of it I did that already has CP/M 3.0 banked CP/M support. Mostly I did that because I wanted 512 byte/sector support as it also supports the use of an SD card for disk.
  2. EtchedPixels

    General technical questions

    With suitable level shifters you can simply wire the 6502 directly to the FPGA. There are similar projects that use a PIC or similar device to do this. Another option, which has its own big set of advantages is to use one of the 6502 FPGA cores and put the entire thing on the FPGA. That way you can have your 32MHz 6502 with 512Kb of banked memory and all the other bits you fancy. Alan
  3. EtchedPixels

    N-Core CPU

    Most of a multi-core CPU is the memory interface. At least you've got dual ported RAM (with the odd fun 'feature' - definitely read the chip documentation!) so some of the horrible bits are done for you.
  4. EtchedPixels

    Grant Searle's Multicomp

    I did look at it a bit, and figured it was easier to wait for the Duo board with SRAM. For now I'll stick the SocZ80. It ain't simple but a 128MHz Z80 makes a wicked CP/M dev box
  5. EtchedPixels

    Instruction set design - request for comments

    You don't need call return providing you can get access to PC somewhere. Ultimately however all 8bit microprocessor designs that pursue elegance evolve into a 6809 (and I say that as a Z80 fan) You don't actually need a lot of instructions to get a pretty effective processor, but how easy it is to program for and how short the code is are rather different questions. The 6502 for example is pretty minimal and quite effective (if a pita to program), while the 8008 is miniscule but does lack a proper stack and arbitrary depth call/return In your instructions set I'd say you can drop NAND (you have NOT and AND), you can drop NOT (XOR). You can in theory even drop SUB as you have ADD and XOR (thus NOT). Some of the bigger machine word systems also didn't have a jump instruction as such, you merely need store-conditional and you can treat program counter as a register. That also makes stacks or register link calls trivial SL/SR can both be replaced with the more useful rotate operation which is as cheap to implement but can do shift left/shift right/ rotate left/rotate right if combined with AND I suspect you can implement call/return and the stack ok as you've got register relative ops so you can use a register of your choice as stack. The only ugly would be that you basically end up doing "load register with constant computed at link time", stick it in (Rstack), Rstack += 2, JMP xx, and your 'RET' is slightly ugly too
  6. EtchedPixels

    ZrT (ZPUino RunTime)

    You could also just watch for patterns on the address bus and trigger an interrupt on those. Not only is it a good debug tool but of course you can interrupt on a device writing to a memory location - and without polling the bus - kind of like PCI MSI
  7. EtchedPixels

    ZrT (ZPUino RunTime)

    I can't think of a generic case but then you would wasting main memory bus bandwidth polling the address rather than being event triggered. The Z80 DMAC can do it (interrupt on match) but it was almost never a win to do so because of the bus contention.
  8. EtchedPixels

    ZrT (ZPUino RunTime)

    If you are doing an rt system then you can hide interrupts from users by making an interrupt an event. You never see an "interrupt" just your thread gets woken up again. Making that work often needs support for priority inversion handling and priorities but I suspect you need them anyway and deadlock detection if you want it to be reasonably userproof. Controllers monitoring bits of I/O space seems sensible - it's not new, floppy controllers generally polled the disk change lines of the disks and turned it into an IRQ. Some ethernet controllers support similar PHY polling schemes so the hardware polls the phy regularly and checks for certain changes.
  9. EtchedPixels

    Flavia: the Free Logic Array

    Thats confusing given that VHDL is a sort of bastardised ADA which is (allegedly) a programming language.
  10. EtchedPixels

    XThunderCore is taking shape

    I can only speak for the Linux case, but I think Linux will be quite happy with physical mappings in supervisor mode. Do you need to force a page size or can you match on a base/mask pair as the 68010/68451 pair did ? Physical without proper caching would be bad though. I guess with 16MB tlbs for the kernel it wouldn't be too bad. I guess the other alternative is segment based addressing 8) There are reasons a lot of the earlier microprocessors with memory protection used segments even if it made programming them less fun in some cases (x86 due to the 16bit size). Does make full virtual memory harder but it makes the MMU architecture much simpler because you cache the entry with the segment register. Would limit you to ucLinux but with protection (although in theory with a bit of core kernel hacking you could also get fork() etc working) or perhaps a retrobsd/2BSD. Would going to 8 or 16K pages help - seems like it would also help for performance, especially if your code isn't very compact. There's definitely going to be a trade-off on how much time you spend reloading TLB entries and efficiency of memory use. 16K pages isn't that unreasonable and x86 is really only 4K nowdays because of compatibility. 16K ought to mean less misses and two less match bits to worry about in the cam Other trick is to ignore some bits of the virtual address space for now (and support it later as needed). Some 64bit cpus do this today. Not sure I'd bother with a context/ASID. If you only have 8 entries then it'll be cheap to save/reload them on a task switch and if that lets you have more TLBs that I imagine would be a bigger win ?
  11. EtchedPixels

    Flavia: the Free Logic Array

    There is plenty wrong with VHDL and Verilog but I have to say the biggest problem I (and I think many people from a programming background) have is the business of thinking in parallel. Not just the idea that things like assignments take time and aren't instant but things like the fact that (except for power in some cases) it's actually not worth doing conditional evaluation of something, you can evaluate it every clock at no extra cost, in fact you can evaluate hundreds of un-needed things for free just in case they are relevant to a given cycle. Not sure a language can help much with that. There is simply a gap between the conceptual model of programming and the reality of FPGA.
  12. EtchedPixels

    XThunderCore is taking shape

    It's nastier than that if you are not very careful. Consider the sequence TLB miss fetch TLB miss handler instruction, oh bugger it's not there -> BOOM and TLB miss fetch instruction save old stack pointer, oh bugger -> BOOM (and thats a general trap handling issue with TLB misses - where do you put the trap vector and restart data that won't itself cause a TLB miss) I would vote for running the TLB miss handler physically mapped. In fact if you don't have many TLB entries, or your TLB entries don't have a size field I'd vote for running "supervisor mode" code physically mapped always. If you've only got fixed size say 4K TLBs then you have to take hits executing kernel code, which is stupid, and you have some other horrible cases (the infamous one is drawing a vertical line on a frame buffer) On x86 we try and do things like map the Linux kernel and its view of physical RAM using large pages, because even with a hardware TLB fetcher and a big TLB the TLB misses hurt. Another approach used by some processors is to in effect sacrifice a couple of bits of virtual address space to "direct mapped" and "uncached" and things like that. Then it becomes address[31] = physical mapped "0"&address[30 down to 0] else TLB If you do that then I think you are probably ok providing the user makes sure their TLB trap vector, code and the like is all in physical space.
  13. EtchedPixels

    XThunderCore is taking shape

    Most of the processors that do this dump enough internal state onto the stack for the trap and then throw the lot at the OS and say "you clean it up". For some processors this was *evil* but usually consisted of a chunk of nasty to understand assembler the manufacturer provided. I would think if your instructions are restartable then you probably only need to know PC of trapping instruction and delay slot flag. At that point you can reconstruct and resume execution (you might need to know if the jump was taken). So I think I'd push condition codes flags [delayslot, etc] onto the trap stack or even push both a trap pc and a resume pc (the same except for delay slots when resume pc is the jump) It becomes something like restartaddr = stack[trap_pc]; if (stack[flags]&DELAY_SLOT) { restartaddr -= JUMP_SIZE stack[trappc] = restartaddr; ret (restores condition code, continues in usermode. The branch will be re-executed and go the same way as before) Probably even hideable in hardware. One thing that's nice about hiding it is that you keep compatibility if your behaviour has to change in future processors (eg x86 hides all sorts of parallelism in the real processor when it comes to throwing exceptions)
  14. EtchedPixels

    SD card wing

    On the store trying to buy one goes to a broken link page ?
  15. EtchedPixels

    Papilio DUO - Classic Computing Shield

    The SD only works in UZI and is a bit iffy as its driving it in SPI mode (1,1) not (0,0) as it should. I've added support for other SPI modes to the spimaster VHDL but only so far tested the 0,0 with ethernet. Once its a bit more tidied up I'll put up a new version of the 'classic' build with CP/M 3.x including SD support, ethernet SPI port etc
  16. EtchedPixels

    Papilio DUO - Classic Computing Shield

    You might also want to look at Will's 'SocZ80'. That's got all the VHDL and bits plus a bit file so you can just drop it onto the Papilio Pro and then fiddle with it. They do seem to grow however. I think I'm going to have to make a case for my SocZ80 now it's got ethernet, SD card and a few other bits dangling off it and is beginning to look more like a jellyfish 8) Alan
  17. EtchedPixels

    LogicStart Shield for the Papilio DUO

    .1 male header is what Ardweenies are used to (plus I guess wanting 5v/3.3v/0v the same way), grove is nice for 'wiring is hard' people - but if you really wanted grove you could easily pull the VGA wing off and add a grove wing could you not ?
  18. EtchedPixels

    LogicStart Shield for the Papilio DUO

    3 pins is nice, four would be awesome on an upward facing connector as it would be enough to play with SPI (MISO, MOSI, CLK, CS) or I²C external widgets. Is there any pin that could easily be shared/jumpered for this (eg losing/sharing an LED)
  19. EtchedPixels

    LogicStart Shield for the Papilio DUO

    http://www.ebay.co.uk/itm/321417153958?_trksid=p2059210.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT is the one I've ordered a couple of - about $5 US inc postage
  20. Neither the Papilio (as far as I can tell) nor the software you'd need (ISE) are available to Iraq. The rules changed not long ago on field programmable devices and I think the low end ones may now be available, but good luck anyone figuring out in a hurry which bits you can obtain.
  21. EtchedPixels

    LogicStart Shield for the Papilio DUO

    Cool.. I bought myself a couple of LCD 320x240 SPI interfaced panels to play with, about about $4 each it was too much to resist 8). Even have a SD card socket on the back!
  22. USB host is hard because its a very complicated protocol you need to speak and the timings are tricky. USB slave is fair bit simpler, at least at the lower speeds. Simply using the USB connector is also not necessarily easy because on most FPGA boards it isn't wired to the FPGA directly in a useful fashion. The other problem for board choice and software is that Haider is in Iraq, and a lot of FPGA devices and software are on the controlled lists so export rules may be a problem (especially as the US enforces them its end with the 'shock and awe' scheme). Hamster: I assume you've seen http://jorisvr.nl/usb/, which only needs a UTMI buffer ? Alan
  23. EtchedPixels

    Ethernet Phy + Magnetics + RJ45 Wing

    Playing with this today getting it working in SocZ80 Useful things I have learned - 10MHz or less - SPI mode 0,0 only - 100nS is needed between deselect and reselect - 100nS is needed between the transaction end and deselection That was far too much fun because the chip responds to just about any SPI protocol timing violation of the above by almost working, everything the mac address writes which mysteriously fail a lot. I have added SPI mode 0 to the SocZ80 SPI master and figured out the delays. Unlike a little microcontroller that the libraries are written for on a 128MHz Z80 on FPGA you can violate them! I can now send and receive packets. On the bright side since we now do SPI 0,0 I can switch Will's SD card driver to use the correct SPI modes, which might explain why some of the cards I have didn't work. Alan
  24. EtchedPixels

    socz80: A Z80 retro microcomputer for the Papilio Pro

    Now I've moved a bit more further progress. I have the base Papilio Pro wired to an SD card and the BIOS changes done so it can drive an SDHC card in CP/M 3. Not terribly important on the Pro, but on the Duo + Retro shield with only 2MB the ramdisk situation will be a bit tighter.
  25. EtchedPixels

    LogicStart Shield for the Papilio DUO

    7segs are a nice learning exercise in strobes and also quite handy for debug on other projects, just with resistors this time perhaps 8) An LCD would be cool but if you have some handy SPI pins on the top or a suitable connector then you already have the bits to hook up one of the little Adafruit displays if wanted, assuming the Papilio Duo can source the 100mA + it needs ?