My 2 GB FAT16 SD has no partitions with default formating.
But my 16 GB FAT32 has 2 Partitions as default as on all Windows drives.
Well, it's one thing how Windows formats a SD per default. The more interesting question is: will Windows deal with a partitioned SD card? The 1GB SD I have here has a partition table, so it seems to be possible. If the Windows onboard tools can't create such a SD, then you could still write to the RAW device to create the partitions as needed.
I knew that NT creates some spare space to keep a copy of vital data. I didn't know that it uses a partition table slot for that purpose.
Anyway, there is even a partition type 0xdb defined for CP/M (probably CP/M86). I'm trying to create such a partition on my SD and see what the digicam and Windows think of it afterwards.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
YES.
To that You only need RAW copy of MBR sector from any HD.
Then edit Partition's INFO regardles to my INFO how it need's be stored in sector 0 at stert position 0.
Important is only YOU correct calculate STARTING - TRACK/HEAD/SECTOR position of Partition X.
In first partition YOU give sector offset TO first Partition in position - 16C - Sectors preceding partition 1 (Number of NON used sectors at start of DRIVE).
Then YOU can use entire UNUSED space as CP/M Drives LOCATION at starting from SECTOR 2 already. For security You can start that CP/M space from SECTOR 4.
AS You can see in HEX dump from - MBR it is even litle space that can be used in it STARTING as - F0 and ending as - 1AF.
Regards
Christoffer J.
PS.
BUT as I said to that we need home made PARTITIONING's program (GOOD it it can runs both on Linux, OEX and Windows.
ONE thing to IF that partitioning program will be corect writen with posibilitys to manualy specify PARTITION size - THEN we can even use it to SD-Cards that are biger as 2GB by partitioning them to 2-2 with 4GB cards and 2-2-2-2 with 8GB cards
PS 2.
TOTALY it can be 4 partitions + Unused space determined in 1 partitions TABLE. As 1 partition alwasy flows after UNUSED space that always must start as sector 1. 0 sector is MBR. 1-3 can YOU have reserved and start CP/M partitions as sector 4
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
YES.
To that You only need RAW copy of MBR sector from any HD.
Then edit Partition's INFO regardles to my INFO how it need's be stored in sector 0 at stert position 0.
Sapieha,
you see, you spent time to collect all this info and my digicam destroys it all. It doesn't accept a SD card with two partitions and refuses to do anything but re-format it. When it formats the SD, it will also write a new partition table with just one partition. Since this will probably be the case with other media using (µ)SD cards, I guess we are out of luck and have to either resort to shrinking the FAT partition by reformatting it, or bite in the apple and use fsrw to access FAT files anyway.
It doesn't make too much sense to risk total data loss caused by whatever you insert the SD card into.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
The Z80 runs noticeably slower with the DracBlade compared to the PropRPM version which used hub RAM for the Z80, but this was to be expected. Anyway, I'm happy it runs at all.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
The Dracblade does run slower than the Blade2 version, but that was to be expected with all the latchings and fetchings. From fading memory the Nascom used to run a 10000 for next loop in 17 secs, but then I cannot remember if that was at its 2MHz or 4MHz setting. The Blade2 is there abouts but the DracBlade is around 22 - 23 secs.
This would not be a problem, for me, as long as the extra opcodes were implimented ( EX, EXX, .... ) the rebuild of Nasbug/NasSys ..... would be possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Yes the speed has never been a big issue for me - more the flexibility of being able to write in multiple languages and mix and match these as part of a total solution. Wordstar is a little slow to load on the dracblade compared with Cluso's boards. And some of the timing constants in xmodem needed tweaking. Compiling a typical program on the simh takes about 3 seconds and on a 4Mhz Z80 machine it is over a minute, so even if the z80 were a 20Mhz chip it still would be faster to do off-board compilation. But who knows were Juergen is taking this...!
How are things going with all the opcodes? The version of zicog I have is the one from about 2 weeks ago with LMM working but only with 8080 opcodes.
Here's the output of ex.com - I always wonder how I manage to break daa,cpl,scf,ccf again and again, because it was already working.
And I can't seem to get the 16 bit adc/sbc right, no matter what I try. There is a bug in there, though, because mbasic behaves strange: it spits an out of memory error when trying to run a simple "Hello world" print loop.
For the io: I wrote my own PASM io handler. As of know it supports FullDuplexSerial and the hard disk emulation, no punch cards, no PS/2 keyboard, no VGA video and no LCD. I'll try to add some or all of them, as memory permits. Otherwise it will be necessary to do it in Spin like Dr_A's current implementation.
Here's the listing comment for yaz80.spin with DracBlade memory handlers:
There are 2 ($002) Longs left in the cog
Woah, that was tight [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Cluso99 said...
The RamBlade will be even faster than TriBlade #2 because sram access is almost 2x faster reading and 1/3 faster writing than TriBlade.
This makes me think: Do you have a triblade.spin and/or ramblade.spin that do the external memory access? I found dracblade.spin, which is based on your code. I hope the functions are similar or the same, then I don't need any ifdefs in the io handler.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Toby Seckshund said...
The Dracblade does run slower than the Blade2 version, but that was to be expected with all the latchings and fetchings. From fading memory the Nascom used to run a 10000 for next loop in 17 secs, but then I cannot remember if that was at its 2MHz or 4MHz setting. The Blade2 is there abouts but the DracBlade is around 22 - 23 secs.
This would not be a problem, for me, as long as the extra opcodes were implimented ( EX, EXX, .... ) the rebuild of Nasbug/NasSys ..... would be possible.
All opcodes are implemented, even (most of) the undocumented ones. The R register is counting and you can read/write the I register. A few opcodes are failing the tests, but I'll get them working eventually.
I guess the Nascom did have ROM? That would require a little tweaking in wr_byte, because it should not write to ROM ranges.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I just found a way to save two operations in the DracBlade address function: if you define the low address and middle address with gate = low, then you don't have to andn #$100 to lower the gate, but just mov outa, outx and then or outa, #$100.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Dr_Acula said...
Sounds intriguing. Have you tested it?
Yes, it's currently running the ex test again. Next I'll try to do the same for the write enable, i.e. gate low at once, then the nop and finally rise gate again.
Edit: Also write access seems to work fine with the gate pin being low in the write enable constant.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
pullmoll: The RamBlade has the data and address pins on different prop pins to make it faster. In ZiCog there were two types of accesses, one block using the TriBlade or RamBlade driver, and the other embedded in the read_byte and write_byte routine. IIRC there was also a lot of #ifdef TriBlades to tristate the address bus in ZiCog if it was going to pass control outside. I don't think this was necessary with RamBlade. This was because I multiplex the pins with the SD card. IIRC Drac does not do this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
pullmoll: The RamBlade has the data and address pins on different prop pins to make it faster. In ZiCog there were two types of accesses, one block using the TriBlade or RamBlade driver, and the other embedded in the read_byte and write_byte routine. IIRC there was also a lot of #ifdef TriBlades to tristate the address bus in ZiCog if it was going to pass control outside. I don't think this was necessary with RamBlade. This was because I multiplex the pins with the SD card. IIRC Drac does not do this.
Ah, okay. That's a clever design. I'll look into ZiCog to find how it's done and add that to my code. I have the TriBladeProp tristate ops in place, so this should already work. I intend to make it easy to run the code on various hardware by just defining the architecture in the top level file.
Edit: Woah. The memory access functions in the ZiCog source for the RamBlade is a mess to say it with friendly words [noparse]:)[/noparse] It's hard to see which code is actually compiled.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Th Nascom1 was 2k monitor rom, 1K VDU ram and 1k (- stack, etc, etc ..) user ram. Wahoo! That way the reset button just got you back to boot, without the Nascom2's restart mplxr. The Nascom2 could be given new memory mapping and I/O roms to turn it into a CP/M beasty, but I never had any of those.
It heavily used the EX, EXX, LDIR and RSTxx instructions. The rom areas will have to be protected, especially as the roms often had self overwriting bombs fitted as standard to stop people copying the code into ram. Bless, (CoughM$).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
pullmoll: The RamBlade is simpler that TriBlade, so I am not sure what you are seeing. I will look for you later. What version are you looking at?
OK, I have checked what you are referring to. An explanation is necessary..
Each of the in and out instructions must tristate the sram bus before passing control to another cog. Each of these instruction variants·are in seperate overlays. Originally they were made as copies of each other. The #ifdef's to add the extra instructions was done in the overlay. These 2 or 4 instructions could be performed as resident code in a call and would greatly simplify the process. However, as you know, the resident code is/was tight. It was felt better to impact the overlay than to impact resident code space where I can gain a huge benefit (not yet done) in placing the RamBlade code inline for fetch, fetch word, read byte and write byte.
DracBlade then required quite a few instructions to set the latches and so we scrounged space for that. Now drac & you have added extra instructions that were not implemented. I had not really looked at what could be saved/pruned within the resident code.
I would need to check, but·IIRC·these instructions are NOT required in RamBlade anyway, only in TriBlade (even though they are still present).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Juergen, are you trying to create one single file with one ifdef at the beginning that can do triblade, ramblade and dracblade?
If so, I think the my code has stabilised enough. Of course, there will be huge amounts of code not compiled for cluso's designs, eg vga and vt100 code etc. But that is ok. I haven't changed my source code much over the last few months, and I don't think Cluso has either, so if you are the main one changing everything we can use your new 'single source' program.
Toby is keen on the Nascom, and with the ldir and ex instructions etc, it sounds like that could be a real possibility soon as well.
Cluso's tristating of the sd card is very cunning. If one could do something similar on the dracblade, it could free up 4 pins. 4 precious pins! I could use two for another serial port, one for analog input and one for analog output. Or other things. I'll think about that some more.
About 6 months back there was a burst of ideas on how to do this thing in software, on that hardware. The result was a whole lot of #ifdefs ....
I tried to go through the code removinge the bits I didn't need, hence my request for the matching sets of #ifdefs and #enddefs to be "highlighted". I soon gave up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Cluso99 said...
pullmoll: The RamBlade is simpler that TriBlade, so I am not sure what you are seeing. I will look for you later. What version are you looking at?
OK, I have checked what you are referring to. An explanation is necessary..
zicog_cpm_rc6.0_rr150-bst-archive-100111-143902.zip it was
Cluso99 said...
Each of the in and out instructions must tristate the sram bus before passing control to another cog. Each of these instruction variants are in seperate overlays. Originally they were made as copies of each other. The #ifdef's to add the extra instructions was done in the overlay. These 2 or 4 instructions could be performed as resident code in a call and would greatly simplify the process. However, as you know, the resident code is/was tight. It was felt better to impact the overlay than to impact resident code space where I can gain a huge benefit (not yet done) in placing the RamBlade code inline for fetch, fetch word, read byte and write byte.
DracBlade then required quite a few instructions to set the latches and so we scrounged space for that. Now drac & you have added extra instructions that were not implemented. I had not really looked at what could be saved/pruned within the resident code.
I would need to check, but IIRC these instructions are NOT required in RamBlade anyway, only in TriBlade (even though they are still present).
Well, okay, that's how it was or is with ZiCog. I was just looking for one read byte / write byte implementation for the RamBlade that I could use. And I was looking for the XMM handler - this is in RamBlade_203_002.spin as it seems and is compatible with a similar piece of code for the TriBlade (which I did not yet find) and the DracBlade (which is in my archive).
I'll be going with the code that is in RamBlade_203_002.spin to implement the read / write in yaz80.spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Toby Seckshund said...
Th Nascom1 was 2k monitor rom, 1K VDU ram and 1k (- stack, etc, etc ..) user ram. Wahoo! That way the reset button just got you back to boot, without the Nascom2's restart mplxr. The Nascom2 could be given new memory mapping and I/O roms to turn it into a CP/M beasty, but I never had any of those.
It heavily used the EX, EXX, LDIR and RSTxx instructions. The rom areas will have to be protected, especially as the roms often had self overwriting bombs fitted as standard to stop people copying the code into ram. Bless, (CoughM$).
Ah, ok. It should be possible to write a Nascom 1K emulation without external RAM then. You'd only have to add the write protect code to yaz80's write byte function and create a TV/VGA renderer for the VDU RAM. You will probably need to modify a keyboard driver to return Nascom's keycodes, too. The latter two are certainly more difficult to do than protecting the ROM from being overwritten.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Dr_Acula said...
Juergen, are you trying to create one single file with one ifdef at the beginning that can do triblade, ramblade and dracblade?
If so, I think the my code has stabilised enough. Of course, there will be huge amounts of code not compiled for cluso's designs, eg vga and vt100 code etc. But that is ok. I haven't changed my source code much over the last few months, and I don't think Cluso has either, so if you are the main one changing everything we can use your new 'single source' program.
Yes, I'm trying to have you all supported by one file, i.e. define all pins and #defines at the top level.
I won't be using your i/o code verbatim, but have written a PASM version peeking at your code. So far it does FullDuplexSerial, the SD card reading/writing, EMM moving using one of the external memory handlers (running in a separate cog), SIMH port handling and the HALT/break handling to display registers.
Dr_Acula said...
Toby is keen on the Nascom, and with the ldir and ex instructions etc, it sounds like that could be a real possibility soon as well.
Yeah. I think he will have more things to do that are not related to the Z80...
Dr_Acula said...
Cluso's tristating of the sd card is very cunning. If one could do something similar on the dracblade, it could free up 4 pins. 4 precious pins! I could use two for another serial port, one for analog input and one for analog output. Or other things. I'll think about that some more.
Well, we have specialists for every aspect of bringing something on its way, or do we? [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/21/2010 10:32:50 AM GMT
I tried this with a comment after the endif, i.e. #endif ' which bloc and BSTC barfed on me. I am used to do this in C, because otherwise the code will pretty soon become unmaintainable. If #endif blah works, then I'm going to add this throughout my code.
DAMNIT!!1!11
Z80 instruction exerciser
Undefined status bits NOT taken into account
<adc,sbc> hl,<bc,de,hl,sp>....( 71,680) cycles ERROR **** crc expected:f39089a0 found:e7f6fb4a
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/21/2010 10:34:29 AM GMT
does work. I think the rule is - no spaces. That is pretty easy use _ instead of space. You can put the ' in if you want. Or not. Just make sure it is all one word.
The easy way for you to get those 4 pins is to sacrifice the colour pallette and go for the 4 pin VGA.
I have yet to built it but I want to put VGA onto P24-27, EEPROM (at boot) and KBD on P28-29. The serial on P30-31 hasn't been picked on, yet. That leaves 24 pins for the ram and SD, and with a sneeky use that probably means 23 for ram, and /CS for the SD.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Comments
Well, it's one thing how Windows formats a SD per default. The more interesting question is: will Windows deal with a partitioned SD card? The 1GB SD I have here has a partition table, so it seems to be possible. If the Windows onboard tools can't create such a SD, then you could still write to the RAW device to create the partitions as needed.
I knew that NT creates some spare space to keep a copy of vital data. I didn't know that it uses a partition table slot for that purpose.
Anyway, there is even a partition type 0xdb defined for CP/M (probably CP/M86). I'm trying to create such a partition on my SD and see what the digicam and Windows think of it afterwards.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
YES.
To that You only need RAW copy of MBR sector from any HD.
Then edit Partition's INFO regardles to my INFO how it need's be stored in sector 0 at stert position 0.
Important is only YOU correct calculate STARTING - TRACK/HEAD/SECTOR position of Partition X.
In first partition YOU give sector offset TO first Partition in position - 16C - Sectors preceding partition 1 (Number of NON used sectors at start of DRIVE).
Then YOU can use entire UNUSED space as CP/M Drives LOCATION at starting from SECTOR 2 already. For security You can start that CP/M space from SECTOR 4.
AS You can see in HEX dump from - MBR it is even litle space that can be used in it STARTING as - F0 and ending as - 1AF.
Regards
Christoffer J.
PS.
BUT as I said to that we need home made PARTITIONING's program (GOOD it it can runs both on Linux, OEX and Windows.
ONE thing to IF that partitioning program will be corect writen with posibilitys to manualy specify PARTITION size - THEN we can even use it to SD-Cards that are biger as 2GB by partitioning them to 2-2 with 4GB cards and 2-2-2-2 with 8GB cards
PS 2.
TOTALY it can be 4 partitions + Unused space determined in 1 partitions TABLE. As 1 partition alwasy flows after UNUSED space that always must start as sector 1. 0 sector is MBR. 1-3 can YOU have reserved and start CP/M partitions as sector 4
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Post Edited (Sapieha) : 3/20/2010 9:34:13 AM GMT
you see, you spent time to collect all this info and my digicam destroys it all. It doesn't accept a SD card with two partitions and refuses to do anything but re-format it. When it formats the SD, it will also write a new partition table with just one partition. Since this will probably be the case with other media using (µ)SD cards, I guess we are out of luck and have to either resort to shrinking the FAT partition by reformatting it, or bite in the apple and use fsrw to access FAT files anyway.
It doesn't make too much sense to risk total data loss caused by whatever you insert the SD card into.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
The Z80 runs noticeably slower with the DracBlade compared to the PropRPM version which used hub RAM for the Z80, but this was to be expected. Anyway, I'm happy it runs at all.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/20/2010 7:10:11 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
This would not be a problem, for me, as long as the extra opcodes were implimented ( EX, EXX, .... ) the rebuild of Nasbug/NasSys ..... would be possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
How are things going with all the opcodes? The version of zicog I have is the one from about 2 weeks ago with LMM working but only with 8080 opcodes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/21/2010 1:58:53 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
And I can't seem to get the 16 bit adc/sbc right, no matter what I try. There is a bug in there, though, because mbasic behaves strange: it spits an out of memory error when trying to run a simple "Hello world" print loop.
For the io: I wrote my own PASM io handler. As of know it supports FullDuplexSerial and the hard disk emulation, no punch cards, no PS/2 keyboard, no VGA video and no LCD. I'll try to add some or all of them, as memory permits. Otherwise it will be necessary to do it in Spin like Dr_A's current implementation.
Here's the listing comment for yaz80.spin with DracBlade memory handlers:
There are 2 ($002) Longs left in the cog
Woah, that was tight [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/21/2010 5:21:05 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
All opcodes are implemented, even (most of) the undocumented ones. The R register is counting and you can read/write the I register. A few opcodes are failing the tests, but I'll get them working eventually.
I guess the Nascom did have ROM? That would require a little tweaking in wr_byte, because it should not write to ROM ranges.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/21/2010 5:45:03 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Edit: Also write access seems to work fine with the gate pin being low in the write enable constant.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/21/2010 9:04:13 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Ah, okay. That's a clever design. I'll look into ZiCog to find how it's done and add that to my code. I have the TriBladeProp tristate ops in place, so this should already work. I intend to make it easy to run the code on various hardware by just defining the architecture in the top level file.
Edit: Woah. The memory access functions in the ZiCog source for the RamBlade is a mess to say it with friendly words [noparse]:)[/noparse] It's hard to see which code is actually compiled.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/21/2010 8:47:45 AM GMT
It heavily used the EX, EXX, LDIR and RSTxx instructions. The rom areas will have to be protected, especially as the roms often had self overwriting bombs fitted as standard to stop people copying the code into ram. Bless, (CoughM$).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
OK, I have checked what you are referring to. An explanation is necessary..
Each of the in and out instructions must tristate the sram bus before passing control to another cog. Each of these instruction variants·are in seperate overlays. Originally they were made as copies of each other. The #ifdef's to add the extra instructions was done in the overlay. These 2 or 4 instructions could be performed as resident code in a call and would greatly simplify the process. However, as you know, the resident code is/was tight. It was felt better to impact the overlay than to impact resident code space where I can gain a huge benefit (not yet done) in placing the RamBlade code inline for fetch, fetch word, read byte and write byte.
DracBlade then required quite a few instructions to set the latches and so we scrounged space for that. Now drac & you have added extra instructions that were not implemented. I had not really looked at what could be saved/pruned within the resident code.
I would need to check, but·IIRC·these instructions are NOT required in RamBlade anyway, only in TriBlade (even though they are still present).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Post Edited (Cluso99) : 3/21/2010 9:57:03 AM GMT
If so, I think the my code has stabilised enough. Of course, there will be huge amounts of code not compiled for cluso's designs, eg vga and vt100 code etc. But that is ok. I haven't changed my source code much over the last few months, and I don't think Cluso has either, so if you are the main one changing everything we can use your new 'single source' program.
Toby is keen on the Nascom, and with the ldir and ex instructions etc, it sounds like that could be a real possibility soon as well.
Cluso's tristating of the sd card is very cunning. If one could do something similar on the dracblade, it could free up 4 pins. 4 precious pins! I could use two for another serial port, one for analog input and one for analog output. Or other things. I'll think about that some more.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/21/2010 9:58:56 AM GMT
I tried to go through the code removinge the bits I didn't need, hence my request for the matching sets of #ifdefs and #enddefs to be "highlighted". I soon gave up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
#ifdef mydef
...
#endif
but once they get nested, who knows what matches what.
I wonder about a new syntax
#ifdef mydef
...
#endif mydef
You can add mydef after endif or you can just use #endif. Indeed, the compiler might not even need to be changed.
Addit: I just tested this, and the compiler does not give an error. So maybe you can add anything after an #endif ?
I just tested
#endif blahblahblah
with no error but I got an error with
#endif blah blah blah
Adding some text after the #endif to say which #ifdef it belongs to would gratly improve readability. No compiler changes needed at all?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/21/2010 10:08:37 AM GMT
Well, okay, that's how it was or is with ZiCog. I was just looking for one read byte / write byte implementation for the RamBlade that I could use. And I was looking for the XMM handler - this is in RamBlade_203_002.spin as it seems and is compatible with a similar piece of code for the TriBlade (which I did not yet find) and the DracBlade (which is in my archive).
I'll be going with the code that is in RamBlade_203_002.spin to implement the read / write in yaz80.spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Ah, ok. It should be possible to write a Nascom 1K emulation without external RAM then. You'd only have to add the write protect code to yaz80's write byte function and create a TV/VGA renderer for the VDU RAM. You will probably need to modify a keyboard driver to return Nascom's keycodes, too. The latter two are certainly more difficult to do than protecting the ROM from being overwritten.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Yes, I'm trying to have you all supported by one file, i.e. define all pins and #defines at the top level.
I won't be using your i/o code verbatim, but have written a PASM version peeking at your code. So far it does FullDuplexSerial, the SD card reading/writing, EMM moving using one of the external memory handlers (running in a separate cog), SIMH port handling and the HALT/break handling to display registers.
Yeah. I think he will have more things to do that are not related to the Z80...
Well, we have specialists for every aspect of bringing something on its way, or do we? [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/21/2010 10:32:50 AM GMT
I tried this with a comment after the endif, i.e. #endif ' which bloc and BSTC barfed on me. I am used to do this in C, because otherwise the code will pretty soon become unmaintainable. If #endif blah works, then I'm going to add this throughout my code.
DAMNIT!!1!11
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/21/2010 10:34:29 AM GMT
does not work but
#endif 'which_bloc
does work. I think the rule is - no spaces. That is pretty easy use _ instead of space. You can put the ' in if you want. Or not. Just make sure it is all one word.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/21/2010 10:38:09 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
The easy way for you to get those 4 pins is to sacrifice the colour pallette and go for the 4 pin VGA.
I have yet to built it but I want to put VGA onto P24-27, EEPROM (at boot) and KBD on P28-29. The serial on P30-31 hasn't been picked on, yet. That leaves 24 pins for the ram and SD, and with a sneeky use that probably means 23 for ram, and /CS for the SD.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point