[N8VEM: 16526] status of 6x0x SBC

[lynchaj]

Hi

I uploaded the most recent schematic and PCB layout for the ECB 6x0x SBC
project. It is getting ready for a prototype board build and test
hopefully in the near future.

Please review the schematic and PCB layout and post any changes and/or
corrections. Specifically I am looking for comments regarding
discrepancies and deficiencies in the board which would prevent build and
test.

As you can see the board is very complex and the PCB is fully packed with
components. Trace routing has proven difficult and there is no more room
for additional components. There have been multiple redesigns. The
schematic and PCB layouts are completely new.

Regarding features the project remains where it was a few weeks ago. It
allows the use of a 6809, 6802, or 6502 CPU with 512KB SRAM and 512KB
Flash.

It contains a serial port (ACIA), programmable timer (PTM), dual parallel
ports (PIA), and a PropTerm subsystem (VGA display, PS/2 keyboard, speaker,
and microSD).

The board includes an RTC with battery backed NVSRAM. There is MMU
circuitry to support addressing memory above 64KB. The SBC has a connector
for interfacing the ECB bus.

The 6x0x SBC can run in standalone mode directly connected to a power
supply, in an ATX case with ATX power supply, or in an 6U (aka VME) chassis.

Please review the schematic and PCB layout files and post your comments.
Please limit to identifying and resolving problems with the current design
and keeping within the traditional design approach of non-programmable TTL
logic, 2 layer PCBs, PTH/DIP/PLCC components, etc.

http://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder&param=ECB%206x0x

Thanks and have a nice day!

Andrew Lynch

[Michael Haardt]

Post by lynchaj
As you can see the board is very complex and the PCB is fully packed with
components. Trace routing has proven difficult and there is no more room
for additional components. There have been multiple redesigns. The
schematic and PCB layouts are completely new.

Would interleaving the sockets for the CPUs help any? After all, you can
only install one at a time.

Michael

[Andrew Lynch]

-----Original Message-----
Behalf Of Michael Haardt
Sent: Tuesday, November 19, 2013 1:24 PM
Subject: Re: [N8VEM: 16526] status of 6x0x SBC

Post by lynchaj
As you can see the board is very complex and the PCB is fully packed
with components. Trace routing has proven difficult and there is no
more room for additional components. There have been multiple
redesigns. The schematic and PCB layouts are completely new.

Would interleaving the sockets for the CPUs help any? After all, you can

only

install one at a time.
Michael

Hi Michael! True enough you can only use on CPU at a time. I think this is
a good idea for the second prototype or production board. I really don't
want to mess with the current prototype board trace routing especially a
nexus point like the 6802/6502 and 6809 interchange.

Maybe a related point is Alex has shown that the 6309 will also work in the
legacy 6x0x boards. That is amazing news to me. Are there any *MINOR*
changes we need to do the current 6x0x to accommodate 6309 or at least not
preclude them from being used?

If (in theory and I am no expert by any stretch) we can accommodate the 6309
and the MMU circuitry is sufficient and effective then possibly NitrOS9
level II is within reach. I hope this is a realistic possibility and comes
to pass. I think it is a worthwhile goal.

Thanks and have a nice day!

Andrew Lynch

[oscarv]

Andrew,

Post by Andrew Lynch
If (in theory and I am no expert by any stretch) we can accommodate the 6309
and the MMU circuitry is sufficient and effective then possibly NitrOS9
level II is within reach. I hope this is a realistic possibility and comes
to pass. I think it is a worthwhile goal.

NitrOS/9 does not need a 6309 anymore, it works with 6809 too.

I think the challenge is to code for 'our' MMU in the nitrOS/9 source code.

Regards,

[Kip Koon]

This post might be inappropriate. Click to display it.

[John Coffman]

Kip,

I can address a couple of the issues that you raise:

6809E vs 6809: this question has been raised before. There are
significant differences between the two chips. The E and Q signals that
need to be generated for the 6809E are generated with one 74LS74. Not a
problem. However, except for the address and data lines, the 6809E has
significantly different signals from the 6809. In interfacing to the
ECB bus for DMA, the 6809 has a more friendly set of signals. Hence,
the choice.

The memory configuration of the current board is pretty much fixed:
512K of SRAM and 512K of ROM. It sounds like NitrOS9 could easily use
more than 512K -- from your descriptions. But the current board is
essentially out of space; it is not a Eurocard 3U (100mm x 160mm); it is
a Eurocard 6U (233mm x 160mm) drilled to fit in an ATX case. It will
fit the N8VEM backplanes as well, if the backplane is bolted into a VME
case. This is _not_ a VME board.

The driving complication for this board is allowing 3 CPU's to use the
circuitry: 6502, 6802, and 6809. This is a legacy requirement, and the
first two chips do not need the MMU. Whether any s/w will be written
for them to use it remains to be seen. The MMU, constructed from
discrete components, is probably a step up from the '612, but it chews
board space. It was added specifically for the 6809 to run NitrOS9 L2.
The big difference will be adapting to the 4K page size.

Your knowledge of NitrOS9 would be invaluable to the s/w effort for this
board and I hope you will be involved in the effort from the beginning.

--John

Post by Kip Koon
Hi Everybody!
My congratulations on redesigning the 6x0x 3-PCB Mezzanine project. I am so
pleased the new 6x0x board project design team is taking such a serious
interest in making the 6809 portion as good as it can be and suitable for
running NitrOS-9. Also that there is concern to make sure Hitachi's HD63C09
will work in place of Motorola's MC68B09.
Coco 3 users have been upgrading from the MC68B09EP to the HD63C09EP for
years with absolutely no motherboard changes required so I suspect the same
is probably true for upgrading from MC68B09Ps to HD63C09Ps. After all,
Hitachi was a second source for a pin for pin compatible 6809 chips to
Motorola's MC68B09(E)P chips for years.
Now I know what you are thinking. The new 6x0x board project is intended for
the MC68B09P and not the MC68B09EP. Well you are right, but how about this
idea. Could a minor change be made to allow either an MC68B09P or an
MC68B09EP MPU to be run on the new 6x0x board with some jumpers nearby to
switch between outputting from the MPU the E & Q clock signals to the ECB
BUS and inputting to the MPU the E & Q clock signals from the ECB BUS? I
need to check the datasheets, but come to think of it jumpers may not be
needed for the E & Q clocks although I imagine there are a few other signals
between the 'non-E' and 'E' versions that might require minor changes to
accommodate them. I just don't know at this point. I'll need to take a
look.
These changes make it possible to have multiple 6x0x boards in the same
system since this new 6x0x board is a single board computer anyway. The
chips connecting the CPU's buses to the ECB BUS could be removed to prevent
conflicts on the ECB BUS.
The now master MC68B09P PCB outputs its E & Q clock signals to the ECB BUS
already since all slave PCBs need these two signals to sync up and function
correctly. The slave MC68B09EP PCBs could use the master clock signals from
the ECB BUS and therefore would automatically be in sync with the master CPU
PCB.
Obviously I'm exploring the possibility of running multiple 6x09s in the
same system and eventually I would need to add several more 6x0x boards with
HD63C09EPs in them so I'm trying to lay some of the ground work now. The
first 6x0x board will have the HD63C09P in it to start my multiprocessor
project off with. Of course that requires inter-processor communications as
well. Maybe some version of this inter-processor communication is already
defined on the ECB Bus since the Z80 use to talk to the 6809 PCB in the
3-PCB Mezzanine setup using a 6522 if memory serves. Maybe this former
inter-processor communication definition could be repurposed and utilized
for this new function or it could go off board with a ribbon cable to make
the inter-processor communications connections with one or more slave
boards. More thought on this is needed.
I've been waiting a long time for the 6x0x board project to get to the point
to where it could run a capable disk based operating system such as NitrOS-9
6x09 L2 and to make it a true single board computer.
I've heard of Flex2 and Flex9, but I have no experience with them nor do I
have anything to run them on similar in nature to the original SWTPC's
computer line. My version of Color Flex is unusable. How much ram could
Flex2 and Flex9 use anyway?
Just a very quick history for those who are not so familiar with NitrOS-9
and its history. After Tandy dropped support for the OS-9 Operating System,
some learned individuals in the Coco community took it upon themselves to
disassemble the entire OS-9 Operating System - boot files, drivers,
descriptors, commands, the whole works. Eventually OS-9 was renamed
NitrOS-9 which is very appropriate since so much has been added to the
original OS-9 Operating System since its inception. These new additions to
OS-9 turning it into NitrOS-9 pretty much made it a requirement that a
minimum of 512KB of ram was essential to make proper use of NitrOS-9 6x09
L2. With new drivers and appropriately formatted descriptors, literally
anything can be interfaced into and operated by NitrOS-9 including all the
features of the new 6x0x board. Heck the original OS-9 system was
originally designed with this capability as a mandatory design feature.
Various versions of OS-9 have been used as an embedded OS in many products
over the years.
An interesting fact about NitrOS-9 6x09 L2 is the current version will
automatically detect and make use of up to 2MB of RAM using the MMU in the
Color Computer 3 with the appropriate memory upgrades! Hopefully the new
MMU in the 6x0x project can be used in a similar way.
When NitrOS-9 is booted in 128KB of ram on the basic unmodified Coco 3,
there is only 3 - 8KB blocks of ram left to run programs. Obviously the
"Out of Memory" error rears its ugly head a lot in this configuration, so
512KB of RAM is now quite necessary. 512KB (I don't remember whether it is
ram, eprom, or a combination of both) have been available for at least some
of the Zilog based N8VEM CPU boards for quite a while now, so you can
imagine how happy I was when talks began towards creating a single board
version of the 3-Board 6x0x Mezzanine setup with 512KB of RAM and 512KB of
eprom included in the new design.
Maybe a subset of the entire NitrOS-9 6x09 L2 80 track DSDD Boot Mini-Disk
will fit into 512KB of Eprom. I imagine that the NITROS9 folder containing
all the routines required to create a new custom boot disk would not be
needed in EPROM and could be included on the SD card instead. Better yet,
since the SD card is present in the new 6x0x design and new drivers would be
needed anyway, the entire complement of the NitrOS-9 software collection
could be stored on the SD Card. 32GB of storage for all of NitrOS-9 is more
than enough including all the plethora of applications! Speaking of the SD
card, WOW! That SD card will add so much more capability to the 6x0x board.
That SD card will make it possible to have multiple OSs and configurations
to be made available for this board. New extensions to Flex2, Flex9 and
UniFlex will be needed as well I imagine. The addition of the SD card is
definitely a great move.
How about including enough pin headers to accommodate two more 512KB Static
RAM chips on a daughter board? A daughter board containing the two
additional 512KB Static RAM chips plus the one that use to be in the socket
which the daughter board now plugs into could easily be designed with female
pin headers to plug into the chip select pin headers on the 6x0x motherboard
and pin headers to plug into the 512KB Static Ram socket. Could this be
done and not affect the MMU design much? Only one more address line would
be needed - ma20. The user would then have options of 512KB, 1MB, 1.5MB or
2MB of ram if the 512KB of eprom is populated with the 512KB static ram chip
as well.
This leads me to my next idea. Can the 512KB of EPROM portion be populated
with a 512KB ram chip and have a much smaller eprom containing smaller
programs like the one in SiMon6809 or Coco 3's DECB 1.1 on a daughter board
since including the much smaller eprom in the current design at this late
stage of the project would require a layout change? This would not
necessitate any design change in the MMU. The logic to deactivate the
portion of the 512KB of address space used for the ram chip which is needed
by the smaller eprom would be on the daughter board. Come to think of it,
all the additional 512KB Static Ram chips, the smaller eprom and the needed
logic could be all on one big daughter board. This would upgrade the new
6x0x board from a 512KB RAM and 512KB EPROM system to a 2MB RAM and 16KB to
32KB Boot EPROM system. Gee, this daughter board is getting kind a big and
the new 6x0x board is still being designed. Cool! That is what all our
collaboration is all about anyway! Maybe I could design this daughter
board. I can now handle 100mm x 160mm PCBs. Isn't that the size of the
EuroCards you all use for all your various ECB Bus computers anyway?
The 16KB to 32KB eprom would be big enough to hold SiMon6809's monitor
program or some modified version of Disk Extended Color Basic with HDB-DOS
or anything else for that matter. In this way, NitrOS-9 6x09 L2, Flex2,
Flex9 or maybe even 6809 UniFlex could be run and have from 512KB -2MB of
RAM in place to make use of depending on whether the 2MB RAM Memory Daughter
Board is present.
Speaking of FLEX2, FLEX9, and UniFlex I noticed in the documentation file
for the new 6x0x board that there is 4KB of address space set aside for I/O.
How much of this I/O address space is actually used for chip addressing?
Couldn't it be reduced to 240 bytes and still accomplish the same functions?
This would give 63.75KB of logical address space for RAM, Eprom and 256
bytes for all the other features and functions including the interrupt
vectors too. I'm sure your MMU takes up a lot less address space than the
Coco 3 version does with the same capabilities of course. I'll have to
reread the new 6x0x docs on that to make sure though.
Couldn't the Flex and UniFlex source code be modified for the new chip
addresses to keep precious logical memory map addressing space used for I/O
at a minimum? I expect the Flex source code would need to be modified
anyway. Couldn't the size of the I/O space be made adjustable to allow for
the bigger address space needed for Flex2, Flex9 and UniFlex and smaller to
allow for other applications like modifying the Coco roms to run on this
platform which only uses 256 bytes or 1/4 of a KB of address space at the
$FF00-$FFEF range for all its I/O including the interrupt vectors?
Earlier I mentioned SiMon6809, for further information on SiMon6809, the
link follows.
http://www.8bitforce.com/simon6809/
In earlier emails I remember someone mentioning that the !FIRQ interrupt
input is not used for much of anything on the new 6x0x board. Relating to
running the SiMon6809 monitor program on this new 6x0x board and one of the
biggest reasons I can see for including the SiMon6809 monitor code into the
design aspects of the new 6x0x board project are three-fold.
First, the SiMon6809 monitor program has a one line assembler source code
entry capability in it. This means you can enter assembly source code into
the monitor program and assembled machine language binary code would be
entered directly into ram. Cool huh!
Second, it can also list the machine language program in memory as assembler
source code since it has an on-the-fly disassembler as well. Perfect for
people like me who have been away from assembling 6809 source code and
disassembling 6809 machine language code for so many years.
Third point is SiMon6809 communicates using a slave Ethernet port and the
!FIRQ interrupt line of the mpu is used in the handshaking process with the
FTDI ethernet chip. This means that 6809 based single board computers need
not be limited to serial I/O any more. FTDI has an excellent prototype
module in a standard 24 pin DIP PCB footprint. This opens up the possibility
of using PC or MAC based file servers at decent data rates. Presently there
are at least two file servers in the Coco community being used that could
possibly be adapted to this board.
I have not looked closely at the schematics yet, so I don't know if a
similar FTDI based slave Ethernet port like what SiMon6809 uses has been
included in the new 6x0x design or not, but if an ethernet port has not been
included, the old code to communicate with the MC6850 ACIA is still there as
comments. I'm sure someone could revamp the old code to communicate with
the 6551 instead. This brings me to another point of concern.
Since the new 6x0x board project does not include a Floppy Drive nor Hard
Drive controllers on board since they are available on other boards via the
ECB Bus, then the top speed for communications of 19,200 Baud is not enough
to use a PC or MAC as a file server. Once I build one of these boards, I
intend to put SiMon6809 on it then to encourage the modification of Disk
Extended Color Basic 1.1 with HDB-DOS 1.4 running out of a portion of the
512KB or smaller eprom so this board will truly have virtual floppy drives
and virtual hard drives for online storage in addition to the utilization of
the SD card until people can afford to upgrade to the full ECB Bus system -
like myself for instance.
In an effort to plan for building one of these new 6x0x boards, I tried to
print out the schematics and look over them, but my laser printer dithers
the colors into black dots to the point that I can't read anything. I have
a Canon LBP-860 which emulates the HP LaserJet Series II printer, so my
Windows 7 systems are printing to an HP LaserJet Series II driver in B/W
only. Is there a way I can convert the pdf version of the color schematics
into a B/W pdf format? No I don't have Adobe's PDF creation software,
though I do have MS Office 2010 which has WORD that can. Maybe the pdfs for
the new 6x0x board project could also be created in all B/W as well?
Please excuse the long email. I tend to think in paragraphs at a time
instead of little bullet points, so please don't flame me. I started out
with just one idea to suggest and to congratulate you all on a job well done
and my mind came up with at least one more idea each time I proof read this
email. After about 7 hours, I'm finally finished. Again, I apologize if
it's too long.
Keep up all the great work all you guys that on all the N8VEM PCB and
Software design teams are doing. I for one am eagerly waiting for the end
result to come to fruition so I can build one. If possible, I'd like to be
included in on the test build team. If you have read this far, thank you.
I certainly enjoyed writing it. Take care my friends.
Kip

[Kip Koon]

Hi John!
Thank you for the explanations and clarifications. That helps to understand
some of the choices that have been made concerning the new 6x0x board
design. I knew there were signal differences between the 6809 and 6809E
mpus, I just could not remember what all they were. I would love to be
involved in the 6x0x ATX board hardware and software development effort.
Maybe a slave 6x0x board can be realized someday.
Thank you for the kind words. I will do my best to help with the software
effort as much as I can. My current NitrOS-9 knowledge has been gleaned
from many people over the last 3 years since I returned back to my computer
roots in 2010. I started off with an early version of the color computer
back in my early 20s, hence my interest in the 6809 today. Since then I
have also grown very fond of the 6309 as well.
I am in the process of trying to get the entire NitrOS-9 source code
distribution to assemble correctly on my windows machine using Cygwin in
place of Linux which is quite an effort considering it is being developed,
assembled and distributed quite successfully from several types of Linux
machines. When I finally get it all to build NitrOS-9 6x09 L2 successfully,
I will let you all know.
There are a few choice people I'd like to get involved with the NitrOS-9
software effort for this machine from the Coco community. I'll make some
inquires to see who might be interested in helping with this project.
Although the 6551 and variants have been utilized in various true RS-232
Cartridge Paks over the years for the coco computer line many if not all of
which have been used with NitOS-9, many of the other chips in this 6x0x
design have not been used with NitrOS-9 before to my knowledge.
However It's a forgone conclusion that fundamental programs that make up the
core of the NitrOS-9 kernel itself will have to be modified and or rewritten
altogether to make use of the new MMU design. I do like the 4K pages
instead of 8KB pages. That will give us 16 pages in the logical memory map
of the 6x09 to work with instead of the 8 pages in the past. This will
obviously affect the size of data areas maintained in the NitrOS-9 kernel.
If I remember correctly from Colossal.pdf, the new 6-bit task register can
switch between 32 possible tasks which will significantly change NitrOS-9's
core routines since the Coco 3 implementation only has 2 possible tasks to
switch between. I have been actually thinking of creating an 8-bit task
register myself in a coco 3 memory upgrade design I have been working on.
I feel I am nowhere near being a master at 6x09 assembly source code
programming nor a master of the software organization and routine
interactions that give NitrOS-9 its capability and power, nor to make the
necessary changes to NitrOS-9 source code itself to adapt it to the new
hardware, but I'm sure it will be very interesting journey to delve into and
start learning it all.
If anybody has an extra VME case laying around, I'd like to acquire it
eventually so I can put this little puppy in a real computer case with a
real backplane once I get it built. Of course I too want to max out the
capabilities of this little board.
I'd also like to make a 6802 version of it and play with at least one of
several possibilities for a disk operating system for that processor as
well. I have a couple of 6802s on hand already. Take care my friend.
Kip

-----Original Message-----
From: n8vem-/***@public.gmane.org [mailto:n8vem-/***@public.gmane.org] On Behalf Of
John Coffman
Sent: Saturday, November 23, 2013 3:15 AM
To: n8vem-/***@public.gmane.org
Subject: Re: [N8VEM: 16557] status of 6x0x SBC

Kip,

I can address a couple of the issues that you raise:

6809E vs 6809: this question has been raised before. There are
significant differences between the two chips. The E and Q signals that
need to be generated for the 6809E are generated with one 74LS74. Not a
problem. However, except for the address and data lines, the 6809E has
significantly different signals from the 6809. In interfacing to the
ECB bus for DMA, the 6809 has a more friendly set of signals. Hence,
the choice.

The memory configuration of the current board is pretty much fixed:
512K of SRAM and 512K of ROM. It sounds like NitrOS9 could easily use
more than 512K -- from your descriptions. But the current board is
essentially out of space; it is not a Eurocard 3U (100mm x 160mm); it is
a Eurocard 6U (233mm x 160mm) drilled to fit in an ATX case. It will
fit the N8VEM backplanes as well, if the backplane is bolted into a VME
case. This is _not_ a VME board.

The driving complication for this board is allowing 3 CPU's to use the
circuitry: 6502, 6802, and 6809. This is a legacy requirement, and the
first two chips do not need the MMU. Whether any s/w will be written
for them to use it remains to be seen. The MMU, constructed from
discrete components, is probably a step up from the '612, but it chews
board space. It was added specifically for the 6809 to run NitrOS9 L2.
The big difference will be adapting to the 4K page size.

Your knowledge of NitrOS9 would be invaluable to the s/w effort for this
board and I hope you will be involved in the effort from the beginning.

--John

Post by Kip Koon
Hi Everybody!
My congratulations on redesigning the 6x0x 3-PCB Mezzanine project. I am so
pleased the new 6x0x board project design team is taking such a serious
interest in making the 6809 portion as good as it can be and suitable for
running NitrOS-9. Also that there is concern to make sure Hitachi's HD63C09
will work in place of Motorola's MC68B09.
Coco 3 users have been upgrading from the MC68B09EP to the HD63C09EP for
years with absolutely no motherboard changes required so I suspect the same
is probably true for upgrading from MC68B09Ps to HD63C09Ps. After all,
Hitachi was a second source for a pin for pin compatible 6809 chips to
Motorola's MC68B09(E)P chips for years.
Now I know what you are thinking. The new 6x0x board project is intended for
the MC68B09P and not the MC68B09EP. Well you are right, but how about this
idea. Could a minor change be made to allow either an MC68B09P or an
MC68B09EP MPU to be run on the new 6x0x board with some jumpers nearby to
switch between outputting from the MPU the E & Q clock signals to the ECB
BUS and inputting to the MPU the E & Q clock signals from the ECB BUS? I
need to check the datasheets, but come to think of it jumpers may not be
needed for the E & Q clocks although I imagine there are a few other signals
between the 'non-E' and 'E' versions that might require minor changes to
accommodate them. I just don't know at this point. I'll need to take a
look.
These changes make it possible to have multiple 6x0x boards in the same
system since this new 6x0x board is a single board computer anyway. The
chips connecting the CPU's buses to the ECB BUS could be removed to prevent
conflicts on the ECB BUS.
The now master MC68B09P PCB outputs its E & Q clock signals to the ECB BUS
already since all slave PCBs need these two signals to sync up and function
correctly. The slave MC68B09EP PCBs could use the master clock signals from
the ECB BUS and therefore would automatically be in sync with the master CPU
PCB.
Obviously I'm exploring the possibility of running multiple 6x09s in the
same system and eventually I would need to add several more 6x0x boards with
HD63C09EPs in them so I'm trying to lay some of the ground work now. The
first 6x0x board will have the HD63C09P in it to start my multiprocessor
project off with. Of course that requires inter-processor communications as
well. Maybe some version of this inter-processor communication is already
defined on the ECB Bus since the Z80 use to talk to the 6809 PCB in the
3-PCB Mezzanine setup using a 6522 if memory serves. Maybe this former
inter-processor communication definition could be repurposed and utilized
for this new function or it could go off board with a ribbon cable to make
the inter-processor communications connections with one or more slave
boards. More thought on this is needed.
I've been waiting a long time for the 6x0x board project to get to the point
to where it could run a capable disk based operating system such as NitrOS-9
6x09 L2 and to make it a true single board computer.
I've heard of Flex2 and Flex9, but I have no experience with them nor do I
have anything to run them on similar in nature to the original SWTPC's
computer line. My version of Color Flex is unusable. How much ram could
Flex2 and Flex9 use anyway?
Just a very quick history for those who are not so familiar with NitrOS-9
and its history. After Tandy dropped support for the OS-9 Operating System,
some learned individuals in the Coco community took it upon themselves to
disassemble the entire OS-9 Operating System - boot files, drivers,
descriptors, commands, the whole works. Eventually OS-9 was renamed
NitrOS-9 which is very appropriate since so much has been added to the
original OS-9 Operating System since its inception. These new additions to
OS-9 turning it into NitrOS-9 pretty much made it a requirement that a
minimum of 512KB of ram was essential to make proper use of NitrOS-9 6x09
L2. With new drivers and appropriately formatted descriptors, literally
anything can be interfaced into and operated by NitrOS-9 including all the
features of the new 6x0x board. Heck the original OS-9 system was
originally designed with this capability as a mandatory design feature.
Various versions of OS-9 have been used as an embedded OS in many products
over the years.
An interesting fact about NitrOS-9 6x09 L2 is the current version will
automatically detect and make use of up to 2MB of RAM using the MMU in the
Color Computer 3 with the appropriate memory upgrades! Hopefully the new
MMU in the 6x0x project can be used in a similar way.
When NitrOS-9 is booted in 128KB of ram on the basic unmodified Coco 3,
there is only 3 - 8KB blocks of ram left to run programs. Obviously the
"Out of Memory" error rears its ugly head a lot in this configuration, so
512KB of RAM is now quite necessary. 512KB (I don't remember whether it is
ram, eprom, or a combination of both) have been available for at least some
of the Zilog based N8VEM CPU boards for quite a while now, so you can
imagine how happy I was when talks began towards creating a single board
version of the 3-Board 6x0x Mezzanine setup with 512KB of RAM and 512KB of
eprom included in the new design.
Maybe a subset of the entire NitrOS-9 6x09 L2 80 track DSDD Boot Mini-Disk
will fit into 512KB of Eprom. I imagine that the NITROS9 folder containing
all the routines required to create a new custom boot disk would not be
needed in EPROM and could be included on the SD card instead. Better yet,
since the SD card is present in the new 6x0x design and new drivers would be
needed anyway, the entire complement of the NitrOS-9 software collection
could be stored on the SD Card. 32GB of storage for all of NitrOS-9 is more
than enough including all the plethora of applications! Speaking of the SD
card, WOW! That SD card will add so much more capability to the 6x0x board.
That SD card will make it possible to have multiple OSs and configurations
to be made available for this board. New extensions to Flex2, Flex9 and
UniFlex will be needed as well I imagine. The addition of the SD card is
definitely a great move.
How about including enough pin headers to accommodate two more 512KB Static
RAM chips on a daughter board? A daughter board containing the two
additional 512KB Static RAM chips plus the one that use to be in the socket
which the daughter board now plugs into could easily be designed with female
pin headers to plug into the chip select pin headers on the 6x0x motherboard
and pin headers to plug into the 512KB Static Ram socket. Could this be
done and not affect the MMU design much? Only one more address line would
be needed - ma20. The user would then have options of 512KB, 1MB, 1.5MB or
2MB of ram if the 512KB of eprom is populated with the 512KB static ram chip
as well.
This leads me to my next idea. Can the 512KB of EPROM portion be populated
with a 512KB ram chip and have a much smaller eprom containing smaller
programs like the one in SiMon6809 or Coco 3's DECB 1.1 on a daughter board
since including the much smaller eprom in the current design at this late
stage of the project would require a layout change? This would not
necessitate any design change in the MMU. The logic to deactivate the
portion of the 512KB of address space used for the ram chip which is needed
by the smaller eprom would be on the daughter board. Come to think of it,
all the additional 512KB Static Ram chips, the smaller eprom and the needed
logic could be all on one big daughter board. This would upgrade the new
6x0x board from a 512KB RAM and 512KB EPROM system to a 2MB RAM and 16KB to
32KB Boot EPROM system. Gee, this daughter board is getting kind a big and
the new 6x0x board is still being designed. Cool! That is what all our
collaboration is all about anyway! Maybe I could design this daughter
board. I can now handle 100mm x 160mm PCBs. Isn't that the size of the
EuroCards you all use for all your various ECB Bus computers anyway?
The 16KB to 32KB eprom would be big enough to hold SiMon6809's monitor
program or some modified version of Disk Extended Color Basic with HDB-DOS
or anything else for that matter. In this way, NitrOS-9 6x09 L2, Flex2,
Flex9 or maybe even 6809 UniFlex could be run and have from 512KB -2MB of
RAM in place to make use of depending on whether the 2MB RAM Memory Daughter
Board is present.
Speaking of FLEX2, FLEX9, and UniFlex I noticed in the documentation file
for the new 6x0x board that there is 4KB of address space set aside for I/O.
How much of this I/O address space is actually used for chip addressing?
Couldn't it be reduced to 240 bytes and still accomplish the same functions?
This would give 63.75KB of logical address space for RAM, Eprom and 256
bytes for all the other features and functions including the interrupt
vectors too. I'm sure your MMU takes up a lot less address space than the
Coco 3 version does with the same capabilities of course. I'll have to
reread the new 6x0x docs on that to make sure though.
Couldn't the Flex and UniFlex source code be modified for the new chip
addresses to keep precious logical memory map addressing space used for I/O
at a minimum? I expect the Flex source code would need to be modified
anyway. Couldn't the size of the I/O space be made adjustable to allow for
the bigger address space needed for Flex2, Flex9 and UniFlex and smaller to
allow for other applications like modifying the Coco roms to run on this
platform which only uses 256 bytes or 1/4 of a KB of address space at the
$FF00-$FFEF range for all its I/O including the interrupt vectors?
Earlier I mentioned SiMon6809, for further information on SiMon6809, the
link follows.
http://www.8bitforce.com/simon6809/
In earlier emails I remember someone mentioning that the !FIRQ interrupt
input is not used for much of anything on the new 6x0x board. Relating to
running the SiMon6809 monitor program on this new 6x0x board and one of the
biggest reasons I can see for including the SiMon6809 monitor code into the
design aspects of the new 6x0x board project are three-fold.
First, the SiMon6809 monitor program has a one line assembler source code
entry capability in it. This means you can enter assembly source code into
the monitor program and assembled machine language binary code would be
entered directly into ram. Cool huh!
Second, it can also list the machine language program in memory as assembler
source code since it has an on-the-fly disassembler as well. Perfect for
people like me who have been away from assembling 6809 source code and
disassembling 6809 machine language code for so many years.
Third point is SiMon6809 communicates using a slave Ethernet port and the
!FIRQ interrupt line of the mpu is used in the handshaking process with the
FTDI ethernet chip. This means that 6809 based single board computers need
not be limited to serial I/O any more. FTDI has an excellent prototype
module in a standard 24 pin DIP PCB footprint. This opens up the possibility
of using PC or MAC based file servers at decent data rates. Presently there
are at least two file servers in the Coco community being used that could
possibly be adapted to this board.
I have not looked closely at the schematics yet, so I don't know if a
similar FTDI based slave Ethernet port like what SiMon6809 uses has been
included in the new 6x0x design or not, but if an ethernet port has not been
included, the old code to communicate with the MC6850 ACIA is still there as
comments. I'm sure someone could revamp the old code to communicate with
the 6551 instead. This brings me to another point of concern.
Since the new 6x0x board project does not include a Floppy Drive nor Hard
Drive controllers on board since they are available on other boards via the
ECB Bus, then the top speed for communications of 19,200 Baud is not enough
to use a PC or MAC as a file server. Once I build one of these boards, I
intend to put SiMon6809 on it then to encourage the modification of Disk
Extended Color Basic 1.1 with HDB-DOS 1.4 running out of a portion of the
512KB or smaller eprom so this board will truly have virtual floppy drives
and virtual hard drives for online storage in addition to the utilization of
the SD card until people can afford to upgrade to the full ECB Bus system -
like myself for instance.
In an effort to plan for building one of these new 6x0x boards, I tried to
print out the schematics and look over them, but my laser printer dithers
the colors into black dots to the point that I can't read anything. I have
a Canon LBP-860 which emulates the HP LaserJet Series II printer, so my
Windows 7 systems are printing to an HP LaserJet Series II driver in B/W
only. Is there a way I can convert the pdf version of the color schematics
into a B/W pdf format? No I don't have Adobe's PDF creation software,
though I do have MS Office 2010 which has WORD that can. Maybe the pdfs for
the new 6x0x board project could also be created in all B/W as well?
Please excuse the long email. I tend to think in paragraphs at a time
instead of little bullet points, so please don't flame me. I started out
with just one idea to suggest and to congratulate you all on a job well done
and my mind came up with at least one more idea each time I proof read this
email. After about 7 hours, I'm finally finished. Again, I apologize if
it's too long.
Keep up all the great work all you guys that on all the N8VEM PCB and
Software design teams are doing. I for one am eagerly waiting for the end
result to come to fruition so I can build one. If possible, I'd like to be
included in on the test build team. If you have read this far, thank you.
I certainly enjoyed writing it. Take care my friends.
Kip

[John Coffman]

Kip,

The best VME rack I have found (FYI: best==cheapest) on eBay is the
Siemens/Simatic rack. They often go for under $20, just keep watching.
There are 3 sizes: 4-, 8-, and 16-slot. The part numbers are 505-6504,
505-6508, and 505-6516. I got an 8-slot job -- shipping was more that
the rack price.

Of course, the VME backplane has to be removed. The N8VEM cards do not
use the VME bus; they use the Kontron bus, and now the Kontron bus
/extended/. The N8VME 8-slot backplane would be appropriate for the
"4-slot" Siemens rack, and the 12-slot backplane would be appropriate
for the "8-slot" rack. Check the pictures of these racks on eBay.

--John

Post by Kip Koon
If anybody has an extra VME case laying around, I'd like to acquire it
eventually so I can put this little puppy in a real computer case with a
real backplane once I get it built. Of course I too want to max out the
capabilities of this little board.

[Borut]

Andrew,

Nice board, i am looking forward to building it.
Is the reason that you have address lines connected to positive chip
selects for PTM, PIA and ACIA because you couldn't route Vcc to those pins
or is it remaining from previous partial decode and could be discarded?
Is any peripheral connected to !FIRQ line? Because if it isn't then AND
function between !FIRQ and !IRQ consisting of U61D and U64C (CPU-6802.sch)
is not necessary,
you could just use !IRQ.
Conn K6 (TIMER.sch) is also practically unnecessary, since you can tie all
three pins together and just use jumper JP12 if you want to use tracing
with ASSIST09 or similar
monitor program.
Would it be possible to add empty narrow (300mils) 24 pin dip pads between
holes P18 and P15, in case we need it for some experiment?

Best regards,
Borut

Post by lynchaj
Hi
I uploaded the most recent schematic and PCB layout for the ECB 6x0x SBC
project. It is getting ready for a prototype board build and test
hopefully in the near future.
Please review the schematic and PCB layout and post any changes and/or
corrections. Specifically I am looking for comments regarding
discrepancies and deficiencies in the board which would prevent build and
test.
As you can see the board is very complex and the PCB is fully packed with
components. Trace routing has proven difficult and there is no more room
for additional components. There have been multiple redesigns. The
schematic and PCB layouts are completely new.
Regarding features the project remains where it was a few weeks ago. It
allows the use of a 6809, 6802, or 6502 CPU with 512KB SRAM and 512KB
Flash.
It contains a serial port (ACIA), programmable timer (PTM), dual parallel
ports (PIA), and a PropTerm subsystem (VGA display, PS/2 keyboard, speaker,
and microSD).
The board includes an RTC with battery backed NVSRAM. There is MMU
circuitry to support addressing memory above 64KB. The SBC has a connector
for interfacing the ECB bus.
The 6x0x SBC can run in standalone mode directly connected to a power
supply, in an ATX case with ATX power supply, or in an 6U (aka VME) chassis.
Please review the schematic and PCB layout files and post your comments.
Please limit to identifying and resolving problems with the current design
and keeping within the traditional design approach of non-programmable TTL
logic, 2 layer PCBs, PTH/DIP/PLCC components, etc.
http://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder&param=ECB%206x0x
Thanks and have a nice day!
Andrew Lynch

[Andrew Lynch]

Hi Borut! Thanks!



1. We could get VCC to the PTM, PIA, and ACIA alternate chip selects
if needed. We are using the address lines to help reduce the enormous
swathes of memory consumed by the current decode scheme. We had to abandon
the previous method of highly focused IO decoding to reduce the number of
chips (many 74LS688s to one 74LS138)

2. I don't think any peripheral is using /FIRQ. The signal is used by
the CPUs and bus buffers but that's it AFAIK.

3. True, the jumpers for the PTM are kind of screwy. They are there
for the ASSIST09 single step mode debugger. I think we can simplify it
after we make the prototype board build and test to determine what is
actually necessary and what is extraneous.

4. I will add a small prototype area with pads in the upper left hand
corner under the parallel and timer IO connectors. There is very little
room so I will add this once the PCB trace routing is better. This can be
added late without too much effort and I don't want to impede the trace
clean up underway at the moment.



Thanks for the review and great observations! Have a nice day!

Andrew Lynch



From: n8vem-/***@public.gmane.org [mailto:n8vem-/***@public.gmane.org] On Behalf Of
Borut
Sent: Tuesday, November 19, 2013 3:16 PM
To: n8vem-/***@public.gmane.org
Subject: [N8VEM: 16528] Re: status of 6x0x SBC



Andrew,

Nice board, i am looking forward to building it.
Is the reason that you have address lines connected to positive chip selects
for PTM, PIA and ACIA because you couldn't route Vcc to those pins
or is it remaining from previous partial decode and could be discarded?
Is any peripheral connected to !FIRQ line? Because if it isn't then AND
function between !FIRQ and !IRQ consisting of U61D and U64C (CPU-6802.sch)
is not necessary,
you could just use !IRQ.
Conn K6 (TIMER.sch) is also practically unnecessary, since you can tie all
three pins together and just use jumper JP12 if you want to use tracing with
ASSIST09 or similar
monitor program.
Would it be possible to add empty narrow (300mils) 24 pin dip pads between
holes P18 and P15, in case we need it for some experiment?

Best regards,
Borut

Dne torek, 19. november 2013 19:11:35 UTC+1 je oseba lynchaj napisala:

Hi



I uploaded the most recent schematic and PCB layout for the ECB 6x0x SBC
project. It is getting ready for a prototype board build and test hopefully
in the near future.



Please review the schematic and PCB layout and post any changes and/or
corrections. Specifically I am looking for comments regarding discrepancies
and deficiencies in the board which would prevent build and test.



As you can see the board is very complex and the PCB is fully packed with
components. Trace routing has proven difficult and there is no more room
for additional components. There have been multiple redesigns. The
schematic and PCB layouts are completely new.



Regarding features the project remains where it was a few weeks ago. It
allows the use of a 6809, 6802, or 6502 CPU with 512KB SRAM and 512KB Flash.




It contains a serial port (ACIA), programmable timer (PTM), dual parallel
ports (PIA), and a PropTerm subsystem (VGA display, PS/2 keyboard, speaker,
and microSD).



The board includes an RTC with battery backed NVSRAM. There is MMU
circuitry to support addressing memory above 64KB. The SBC has a connector
for interfacing the ECB bus.



The 6x0x SBC can run in standalone mode directly connected to a power
supply, in an ATX case with ATX power supply, or in an 6U (aka VME) chassis.



Please review the schematic and PCB layout files and post your comments.
Please limit to identifying and resolving problems with the current design
and keeping within the traditional design approach of non-programmable TTL
logic, 2 layer PCBs, PTH/DIP/PLCC components, etc.



http://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder
<http://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder&param=ECB%206x0x>
&param=ECB%206x0x



Thanks and have a nice day!

Andrew Lynch
--
You received this message because you are subscribed to the Google Groups
"N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

[Borut]

Hi Andrew

1. I don't see how that works, since you are using different output of
74ls138 for each peripheral.
What would work would be the same chip select from 74ls138 and different
address lines for each peripheral.
In that case you have to start with mA4, since VIAs use mA0-mA3. I
described the idea in a previous post.

2. In that case those gates are probably not necessary and it might
infinitesimally simplify the design.

3. I have all three pins connected together on my N8VEM standalone 6809
board, running ASSIST09 and trace (single step) kinda works.
I think there is a bug in assist, since it garbles the eeprom if i use
28C16, so i am using 2716.
Also the breakpoints in my version of ASSIST09 don't work.

4.Thanks for the prototyping pads. The more the better.

Best regards,

Borut

Post by Andrew Lynch
Hi Borut! Thanks!
1. We could get VCC to the PTM, PIA, and ACIA alternate chip
selects if needed. We are using the address lines to help reduce the
enormous swathes of memory consumed by the current decode scheme. We had
to abandon the previous method of highly focused IO decoding to reduce the
number of chips (many 74LS688s to one 74LS138)
2. I don’t think any peripheral is using /FIRQ. The signal is used
by the CPUs and bus buffers but that’s it AFAIK.
3. True, the jumpers for the PTM are kind of screwy. They are
there for the ASSIST09 single step mode debugger. I think we can simplify
it after we make the prototype board build and test to determine what is
actually necessary and what is extraneous.
4. I will add a small prototype area with pads in the upper left
hand corner under the parallel and timer IO connectors. There is very
little room so I will add this once the PCB trace routing is better. This
can be added late without too much effort and I don’t want to impede the
trace clean up underway at the moment.
Thanks for the review and great observations! Have a nice day!
Andrew Lynch
*Sent:* Tuesday, November 19, 2013 3:16 PM
*Subject:* [N8VEM: 16528] Re: status of 6x0x SBC
Andrew,
Nice board, i am looking forward to building it.
Is the reason that you have address lines connected to positive chip
selects for PTM, PIA and ACIA because you couldn't route Vcc to those pins
or is it remaining from previous partial decode and could be discarded?
Is any peripheral connected to !FIRQ line? Because if it isn't then AND
function between !FIRQ and !IRQ consisting of U61D and U64C (CPU-6802.sch)
is not necessary,
you could just use !IRQ.
Conn K6 (TIMER.sch) is also practically unnecessary, since you can tie all
three pins together and just use jumper JP12 if you want to use tracing
with ASSIST09 or similar
monitor program.
Would it be possible to add empty narrow (300mils) 24 pin dip pads between
holes P18 and P15, in case we need it for some experiment?
Best regards,
Borut
Hi
I uploaded the most recent schematic and PCB layout for the ECB 6x0x SBC
project. It is getting ready for a prototype board build and test
hopefully in the near future.
Please review the schematic and PCB layout and post any changes and/or
corrections. Specifically I am looking for comments regarding
discrepancies and deficiencies in the board which would prevent build and
test.
As you can see the board is very complex and the PCB is fully packed with
components. Trace routing has proven difficult and there is no more room
for additional components. There have been multiple redesigns. The
schematic and PCB layouts are completely new.
Regarding features the project remains where it was a few weeks ago. It
allows the use of a 6809, 6802, or 6502 CPU with 512KB SRAM and 512KB Flash.
It contains a serial port (ACIA), programmable timer (PTM), dual parallel
ports (PIA), and a PropTerm subsystem (VGA display, PS/2 keyboard, speaker,
and microSD).
The board includes an RTC with battery backed NVSRAM. There is MMU
circuitry to support addressing memory above 64KB. The SBC has a connector
for interfacing the ECB bus.
The 6x0x SBC can run in standalone mode directly connected to a power
supply, in an ATX case with ATX power supply, or in an 6U (aka VME) chassis.
Please review the schematic and PCB layout files and post your comments.
Please limit to identifying and resolving problems with the current design
and keeping within the traditional design approach of non-programmable TTL
logic, 2 layer PCBs, PTH/DIP/PLCC components, etc.
http://n8vem-sbc.pbworks.com/w/browse/#view=ViewFolder&param=ECB%206x0x<http://www.google.com/url?q=http%3A%2F%2Fn8vem-sbc.pbworks.com%2Fw%2Fbrowse%2F%23view%3DViewFolder%26amp%3Bparam%3DECB%25206x0x&sa=D&sntz=1&usg=AFQjCNEeAwTK3fZqBp7-DKlLOZ2rE0dXrw>
Thanks and have a nice day!
Andrew Lynch
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

[John Coffman]

Borut,

Post by Borut
Is the reason that you have address lines connected to positive chip
selects for PTM, PIA and ACIA because you couldn't route Vcc to those pins
or is it remaining from previous partial decode and could be discarded?

I noticed this too in going over the schematic. I assume it is a legacy
from the former board's I/O decode. I don't really know the effect on
the trace route -- whether it complicates it or simplifies it -- but it
should present no programming problems. Good practice equates all the
chip registers to numeric constants, and the chip is thus programmed
symbolically.

Post by Borut
Is any peripheral connected to !FIRQ line? Because if it isn't then
AND function between !FIRQ and !IRQ consisting of U61D and U64C
(CPU-6802.sch) is not necessary,
you could just use !IRQ.

AFAIK, nothing is connected to /FIRQ. I think the AND should be kept,
in case there is some reason to switch some peripheral to use /FIRQ
(through board surgery on the prototype).

Post by Borut
Conn K6 (TIMER.sch) is also practically unnecessary, since you can tie
all three pins together and just use jumper JP12 if you want to use
tracing with ASSIST09 or similar
monitor program.

I guess this is just another legacy from earlier boards.

--John

[littlebus]

Terrific project, Andrew.

If the HD6309 one of the optional MPUs then (according to the datasheet)
the only difference to the 6809 is that the xtal input needs to be floating
instead of tied to grd. Linked jumper pads on this trace?

Best Wishes,

Clive.

[Andrew Lynch]

Hi Clive! Thanks! Good idea.



Yes, I will add a jumper to ground on 6809 pin 39.



Thanks and have a nice day!

Andrew Lynch



From: n8vem-/***@public.gmane.org [mailto:n8vem-/***@public.gmane.org] On Behalf Of
littlebus
Sent: Wednesday, November 20, 2013 6:55 AM
To: n8vem-/***@public.gmane.org
Subject: [N8VEM: 16530] Re: status of 6x0x SBC




Terrific project, Andrew.

If the HD6309 one of the optional MPUs then (according to the datasheet)
the only difference to the 6809 is that the xtal input needs to be floating
instead of tied to grd. Linked jumper pads on this trace?

Best Wishes,

Clive.
--
You received this message because you are subscribed to the Google Groups
"N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

[AG5AT]

Andrew and all,

I am not sure that having pin 39 float is a necessity for the HD6309. I am
running HD63C09P's in two of the 6x0x boards and they are running fine with
pin 39 grounded.

Aug

Post by Andrew Lynch
Hi Clive! Thanks! Good idea.
Yes, I will add a jumper to ground on 6809 pin 39.
Thanks and have a nice day!
Andrew Lynch
*Sent:* Wednesday, November 20, 2013 6:55 AM
*Subject:* [N8VEM: 16530] Re: status of 6x0x SBC
Terrific project, Andrew.
If the HD6309 one of the optional MPUs then (according to the datasheet)
the only difference to the 6809 is that the xtal input needs to be floating
instead of tied to grd. Linked jumper pads on this trace?
Best Wishes,
Clive.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

[oscarv]

Hi,

I took a stroll through the NitrOS/9 kernel code today. Although I'm (very)
far from knowledgeable on things NitrOS & 6809, I am starting to wonder how
non-trivial it will be when porting NitrOS/9 from 8K memory blocks to 4K
memory blocks. It means, obviously, changing some memory allocation
functions.

But it also means, for instance, that the Block Map which keeps track of
block assignments either doubles in size to deal with 4K blocks, infringing
on other things in the Nitros memory map – or reducing available memory by
half.

A 'stroll through the kernel' code is not a very meaningful base for
judgment… but has any Nitros/9 expert thought about the topic of moving to
4K blocks? I clearly see the benefit but the price in Nitros/9 porting &
compatibility is worth finding out.



Regards,

Oscar.

[John Coffman]

Oscar,

If worse comes to worse, with 4K blocks one can allocate them 2 at a
time. Equivalent to 8K blocks.

--John

Hi,
I took a stroll through the NitrOS/9 kernel code today.Although I'm
(very) far from knowledgeable on things NitrOS & 6809, I am starting
to wonder how non-trivial it will be when porting NitrOS/9 from 8K
memory blocks to 4K memory blocks. It means, obviously, changing some
memory allocation functions.
But it also means, for instance, that the Block Map which keeps track
of block assignments either doubles in size to deal with 4K blocks,
infringing on other things in the Nitros memory map – or reducing
available memory by half.
A 'stroll through the kernel' code is not a very meaningful base for
judgment… but has any Nitros/9 expert thought about the topic of
moving to 4K blocks? I clearly see the benefit but the price in
Nitros/9 porting & compatibility is worth finding out.
Regards,
Oscar.
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/groups/opt_out.

[oscarv]

John,

Post by John Coffman
If worse comes to worse, with 4K blocks one can allocate them 2 at a
time. Equivalent to 8K blocks.

Bloops. Of course... I was staring myself blind on how 8K blocks could be
done electronically, or how to move to 4K blocks all across the Nitros
kernel.

Thanks!

Oscar.

[John Coffman]

Oscar,

Allocating 2 x 4k blocks would be a quick way to get going. I'd hope
that we could understand the kernel algorithms and move to 4k blocks
eventually.

BTW: Is the source in the public domain? If so, could you post a link
to it, or post it on the Wiki? Also, the tools for
cross-compiling/assembling it. I'm a complete neophyte in this area.

--John

Post by John Coffman
John,
If worse comes to worse, with 4K blocks one can allocate them 2 at a
time. Equivalent to 8K blocks.
Bloops. Of course... I was staring myself blind on how 8K blocks could
be done electronically, or how to move to 4K blocks all across the
Nitros kernel.
Thanks!
Oscar.

[oscarv]

John,

The source tree is here (link)<http://sourceforge.net/apps/mediawiki/nitros9/index.php?title=Building_NitrOS9>.
You first need to get LWTools and the Toolshed as described on the page -
although the latter is only for building the final disk images.

I ended up doing this on Ubuntu, a Windows build attempt became frustrating
due to my complicated relationship with make under Windows, I guess.
In the code archive, the kernel is what I spent my time on:
../nitros9/level2/modules/kernel . It is well documented code.

The documentation is quite good too, here (link)<http://sourceforge.net/apps/mediawiki/nitros9/index.php?title=Main_Page>
.

At least it is becoming clear to me that it (seems) not too difficult to
cut the graphics part out and run Nitros9 from a terminal. The CoCo version
itself already supports a terminal on a serial port (either a bit-banged
one or one using 6551 ACIA in an expensaion pack).

Also, have a look at CoCo3 emulator VCC (link <http://www.coco4.com/vcc/>)
and the Nitros9 level 2 hard disk image (link<http://www.coco4.com/data/vcc/nitros9.zip>)
that goes with it. It took me a while. DOS 255 is what makes the CoCo3 boot
Nitros/9.

Regards,

Oscar.