Re: [M100] OS9 for M100?
I can throw in a few $...but am limited budgeted. I do like seeing real stuff get done. Thanks all. Sent from my iPhone On May 2, 2016, at 4:34 PM, "John R. Hogerhuis"wrote: > > > On Monday, May 2, 2016, Ken Pettit wrote: > Thanks Gary! I didn't even think about something like Kickstarter 4 years > ago. Might be an interesting effort to post something there and see what > type of support it receives. :) > > Ken > > Have to make sure to publicize it in retrocomputing community if you went > that way. And I'm sure there are still some nostalgic reporters that loved > the model 100 that would throw some funds at it. There'd be interest beyond > our little sewing circle here just hard to say how much. > > Best case it actually gets fabricated in silicon and custom plastics if > there's real funding. > > For real success there would have to be applications outside retrocomputing. > > -- John.
Re: [M100] OS9 for M100?
On 5/2/16 4:34 PM, John R. Hogerhuis wrote: Best case it actually gets fabricated in silicon and custom plastics if there's real funding. Yeah, my mind keeps asking "How can I slip this into the ASIC I'm working on at the office" :) Ken
Re: [M100] OS9 for M100?
On Monday, May 2, 2016, Ken Pettitwrote: > Thanks Gary! I didn't even think about something like Kickstarter 4 > years ago. Might be an interesting effort to post something there and see > what type of support it receives. :) > > Ken > Have to make sure to publicize it in retrocomputing community if you went that way. And I'm sure there are still some nostalgic reporters that loved the model 100 that would throw some funds at it. There'd be interest beyond our little sewing circle here just hard to say how much. Best case it actually gets fabricated in silicon and custom plastics if there's real funding. For real success there would have to be applications outside retrocomputing. -- John.
Re: [M100] OS9 for M100?
Thanks Gary! I didn't even think about something like Kickstarter 4 years ago. Might be an interesting effort to post something there and see what type of support it receives. :) Ken On 5/2/16 4:15 PM, Gary Weber wrote: On Mon, May 2, 2016 at 4:08 PM, Ken Pettit> wrote: > I had most (or maybe all) of this tested and working 4 years ago as I recall. On 5/2/16 4:01 PM, John R. Hogerhuis wrote: > So where do I buy one :-) Take my money, now! I share this sentiment as well! Brilliant idea, Ken. Sure would be an interesting and quite useful hybrid laptop machine, indeed. If you started a Kickstarter or a GoFundMe, I would be there to "encourage" you in this endeavor. ;-) Gary
Re: [M100] OS9 for M100?
Oh I know another reason to use special NOPs. NOPs are opcode 00 so which tends to be a special character. Probably some or all NOP-alternatives can be embedded directly in BASIC string literals. And don't think BASIC file I/O can be used for NULs. So whatever. They are minor edge cases and they could be addressed as necessary with patches. -- John.
Re: [M100] OS9 for M100?
On Mon, May 2, 2016 at 3:58 PM, Ken Pettitwrote: > Really? Something uses "MOV A,A". It's just a NOP. Who would have > thought. > > Ken > > I was thinking maybe they were going for a specific cycle count but it looks like a NOP should be the same cycle count as mov a,a (4) I'd guess it was either a multiple entry instruction or someone just doing it because they could. The mood/mov struck... -- John.
Re: [M100] OS9 for M100?
I just looked at my files for the extended 8085. They are all dated April 2012! Has it really been 4 years since I worked on that stuff? Man time sure does fly by. Anyway, I saw that I also remapped the RSTV opcode since it is basically useless in the M100 ROM, and I also have extended opcodes for LJMP and LCALL (24-bit JMP and CALL). That project was built around an Actel IGLOO chip (sitting on a board with limited peripherals). I should dust off that project and get it running on my Digilent NEXYS 4 or Zedboard board. Ken On 5/2/16 3:18 PM, John R. Hogerhuis wrote: On Mon, May 2, 2016 at 3:01 PM, Ken Pettit> wrote: I used the MOV A,A MOV B,B, MOV C,C, etc. opcodes and remaped them. Clever! As you know though there's all kinds of strange code in the ROM used in "byte fighter" techniques where the programmer coded a jump into the middle of an instruction effectively creating multiple entry points into the same instruction with different outcomes depending on the entry point. Did Bill ever use those opcodes as "special no-ops"? -- John.
Re: [M100] OS9 for M100?
On Mon, May 2, 2016 at 3:01 PM, Ken Pettitwrote: > I used the MOV A,A MOV B,B, MOV C,C, etc. opcodes and remaped them. Clever! As you know though there's all kinds of strange code in the ROM used in "byte fighter" techniques where the programmer coded a jump into the middle of an instruction effectively creating multiple entry points into the same instruction with different outcomes depending on the entry point. Did Bill ever use those opcodes as "special no-ops"? -- John.
Re: [M100] OS9 for M100?
No, a CPLD wouldn't do it. The Complex Instruction architecture of the 8085 causes the gate count to be way to high for a CPLD. Even before adding any extended instructions / addressing modes. Ken On 5/2/16 3:00 PM, Stephen Adolph wrote: I think there might be some better low power options now, than years ago. I have not looked into it at all. A CPLD implementation does not seem likely given the need for DLLs and timing circuits. Ken might know? On Mon, May 2, 2016 at 5:40 PM, John R. Hogerhuiswrote: On Mon, May 2, 2016 at 2:38 PM, Stephen Adolph wrote: I recall now... I knew I had none of the answers but I knew you would! So, what did you do to create the new instructions? And I'm interested to hear about the relative power consumption. -- John.
Re: [M100] OS9 for M100?
I used the MOV A,A MOV B,B, MOV C,C, etc. opcodes and remaped them. The new instructions I added are: SBcc - Short conditional branch == Branches +31 / -32 conditionally using 1 byte following the opcode (4 conditions) (2 byte opcode) BR - Branch == Branches +127 -128 using 1 byte following the opcode (2 byte opcode) Bcc - Conditional branch == Branches +4095 / - 4096 relative conditionally (8 conditions) (3 byte opcode) Rcall - Relative CALL == CALL relative +32767 / -32768 (3 byte opcode) STP - Set Page == Set the Extended address page (bits 23-16) from the contents of A. Each 16-bit register has it's own extended address page (HL, DE, BC, SP, PC, plus one for indirect opcodes such as STA, LDA, SHLD, LHLD) The current page directs indirect (HL), (DE), (BC) accesses to occur in a different 64K region GTP - Get Page Get the Extended address page (bits 23-16) into A LPUSH == Push 24 bit versions of HL, DE, BC, SP LPOP == Pop 24 bit versions of HL, DE, BC, SP LRET == Return from a subroutine using 3 byte address POPed into PC from stack Ken On 5/2/16 2:38 PM, Stephen Adolph wrote: I recall now... I knew I had none of the answers but I knew you would! So, what did you do to create the new instructions? On Mon, May 2, 2016 at 5:29 PM, Ken Pettitwrote: I already have that. It supports 16M address space plus I already patched the ROM so the ISR functions properly jump to the the lower 64K region and return to the upper regions if needed. Ken On 5/2/16 1:32 PM, Stephen Adolph wrote: ok, here is a proposal. Let's get a small FPGA and make an 80c85V2 that includes extra instructions...make it retro compatible. On Mon, May 2, 2016 at 4:19 PM, John R. Hogerhuis wrote: On Monday, May 2, 2016, Bruce H McIntosh wrote: On 2016-05-01 03:03, Hiraghm wrote: I know awhile back folks were talking about a CP/M port for the Model T. Earlier today I was watching some Youtube videos on CP/M, which reminded me of OS/9, and that got me wondering. OS9 is re-entrant and position independent, multi-user and multi-tasking. The original OS9 was designed to operate in 64k of ram. OS/9 had a lot of stuff that relied utterly upon the 6809 CPU's architectural quirks. It was eventually ported to the 68000 and 80386. The 8085 might be a bit of a stretch. https://en.wikipedia.org/wiki/OS-9 And it would be slow. You would have to use some expensive tricks to simulate position independent code. CP/M is way more doable and opens up access to a lot of compilers and other applications. The roadmap and hardware is all there for the cp/m project. Just need the people and gumption to get it done. -- John.
Re: [M100] OS9 for M100?
I think there might be some better low power options now, than years ago. I have not looked into it at all. A CPLD implementation does not seem likely given the need for DLLs and timing circuits. Ken might know? On Mon, May 2, 2016 at 5:40 PM, John R. Hogerhuiswrote: > > > On Mon, May 2, 2016 at 2:38 PM, Stephen Adolph wrote: >> >> I recall now... I knew I had none of the answers but I knew you would! >> So, what did you do to create the new instructions? >> > > And I'm interested to hear about the relative power consumption. > > -- John.
Re: [M100] OS9 for M100?
On Mon, May 2, 2016 at 2:38 PM, Stephen Adolphwrote: > I recall now... I knew I had none of the answers but I knew you would! > So, what did you do to create the new instructions? > > And I'm interested to hear about the relative power consumption. -- John.
Re: [M100] OS9 for M100?
ok, here is a proposal. Let's get a small FPGA and make an 80c85V2 that includes extra instructions...make it retro compatible. On Mon, May 2, 2016 at 4:19 PM, John R. Hogerhuiswrote: > > > On Monday, May 2, 2016, Bruce H McIntosh wrote: >> >> On 2016-05-01 03:03, Hiraghm wrote: >>> >>> I know awhile back folks were talking about a CP/M port for the Model T. >>> Earlier today I was watching some Youtube videos on CP/M, which reminded >>> me of OS/9, and that got me wondering. >>> OS9 is re-entrant and position independent, multi-user and multi-tasking. >>> The original OS9 was designed to operate in 64k of ram. >>> >> OS/9 had a lot of stuff that relied utterly upon the 6809 CPU's >> architectural quirks. It was eventually ported to the 68000 and 80386. The >> 8085 might be a bit of a stretch. >> >> https://en.wikipedia.org/wiki/OS-9 >> > > And it would be slow. You would have to use some expensive tricks to > simulate position independent code. > > CP/M is way more doable and opens up access to a lot of compilers and other > applications. The roadmap and hardware is all there for the cp/m project. > Just need the people and gumption to get it done. > > -- John.
Re: [M100] OS9 for M100?
On Monday, May 2, 2016, Bruce H McIntoshwrote: > On 2016-05-01 03:03, Hiraghm wrote: > >> I know awhile back folks were talking about a CP/M port for the Model T. >> Earlier today I was watching some Youtube videos on CP/M, which reminded >> me of OS/9, and that got me wondering. >> OS9 is re-entrant and position independent, multi-user and multi-tasking. >> The original OS9 was designed to operate in 64k of ram. >> >> OS/9 had a lot of stuff that relied utterly upon the 6809 CPU's > architectural quirks. It was eventually ported to the 68000 and 80386. The > 8085 might be a bit of a stretch. > > https://en.wikipedia.org/wiki/OS-9 > > And it would be slow. You would have to use some expensive tricks to simulate position independent code. CP/M is way more doable and opens up access to a lot of compilers and other applications. The roadmap and hardware is all there for the cp/m project. Just need the people and gumption to get it done. -- John.
Re: [M100] OS9 for M100?
On 2016-05-01 03:03, Hiraghm wrote: I know awhile back folks were talking about a CP/M port for the Model T. Earlier today I was watching some Youtube videos on CP/M, which reminded me of OS/9, and that got me wondering. OS9 is re-entrant and position independent, multi-user and multi-tasking. The original OS9 was designed to operate in 64k of ram. OS/9 had a lot of stuff that relied utterly upon the 6809 CPU's architectural quirks. It was eventually ported to the 68000 and 80386. The 8085 might be a bit of a stretch. https://en.wikipedia.org/wiki/OS-9 -- Bruce H. McIntosh scots...@afn.org www.afn.org/~scotsman WA4UF Network geek with a strong affinity for Telecasters