Date   
Re: UT62 and Basic

cmdrcosmac
 

Earlier I posted about a problem running RCA's Basic 3 on my
SuperElf.
 Basic would run 1 line and stop. I've since recalled that
the old basic's often checked the terminal's BREAK key so
the user could escape a loop. Since the system's serial
comms used /EF4 that was a clue. Basic had to be checking
/EF4 independently of UT62's use of /EF4.
 So I whipped up a disassembler and Lo and Behold...

              SEP 5          .. D5                   B137 0257 Õ
              B4     #3E    .. 373E   Label19  B138 0258 7>
Label20:  BN4   #3A   .. 3F3A   Label20  B13A 0259 :
              SMI    #00    .. FF00                B13C 0260 ÿ.
Label19:  SEP 5         .. D5                    B13E 0261 Õ

So I restarted the system, held the Elf's Input key,
(which controls /EF4) and ran the Basic program again.
This time it acted correctly, like it did under Emma 02.
There are other B4's and BN4's in the Basic, but I have
left them alone for now.
 So some of the mystery solved. perhaps Marcel or Herb might
know something about the other /EF4 branches in there.
Since I am not much of a Basic programmer I ask could someone
post or point me to more basic programs that might use to
test with.
Much thanks,
Chuck

A video of my 1802 tester made from Arduino Mega

jeff.birt
 

With a lot of help and encouragement form this mailing list I put together this Arduino Mega 2560 powered 1802 tester to test the lot of 10, 1802s I bought from a seller in China. While the initial simple set up was sufficient to find I had two bad chips it was fun to improve upon the test rig and I learned a lot about the 1802 in the process.

As luck would have it the serial command input quit responding during the video but has worked every time since. I left it in as that is what happens in real life, things always fail in a demo :)

https://youtu.be/XPwuwjtjXnk

Jeff Birt

 

Re: Elf2k V88 needs Terminal Local Echo set to ON

ajparent1/kb1gmx
 

Likely so as some terminals did it for you  (especially ASR33) while other much later like
most glass tubes it was something that the terminal could do for it self or the system did it.

Allison

Re: Todd's ELF-ish to get an FDC #Homebrew #microboards

ajparent1/kb1gmx
 

DMA, you don't have a choice there. either that or a new design with a 8mhz 1806 minimum.

I did it that way, dma decided by WE (drive write commend). that and a few gates I
forget if I used 7400 or 7432 and an inverter.  The goal was fewer wires to get in
the wrong places.  I used the 37C65 as a I had a few back when.

Re: Todd's ELF-ish to get an FDC #Homebrew #microboards

taf123
 

Thanks for all of that Allison.  Definitely was planning on using the DMA mode.  Jumper select-able between EF-x polling and Interrupt use.

I like the idea of using the WE for DMA direction.  I'll go ahead and build it as-is (RCA) but could always retro-fit that change later. Ah, the joys of wire-wrap.

Best regards,
Todd

Re: Todd's ELF-ish to get an FDC #Homebrew #microboards

ajparent1/kb1gmx
 

The 18series board was developed off the early NEC apnote.  I pounded on them (RCA back then) to
jump to the digital data separator that was much lower in parts count and NO adjustments. 
Same for the other suggestion (DMA selection).  I believe they eventually did but have no
documents to say.

Any who yes 9266 and later 37C65 series parts made the whole mess as small as one chip (37C65).

One thing the logic to determine DMA-in or DMA-out is simplified if you use the WRITE signal out
(pin25 FDC WE) of the FDC.  Then you need no logic hardware of software to control DMA direction. 
Also programming for FDC for PIO is nearly out of the range of what 1802 can do fast enough
unless clocked very fast.  The DMA interface is used for that and PIO only for command and status. 
FYI: the FDC running at DD high rate formats will want or spit a byte every 16uS during write or
read to media, the slowest format (SD 5.25) also being the least dense is 64us per byte.  Failure
to do that results in underrun/overrun as the FDC has minimal buffering and if that happens that sector is trashed.

Interrupt is not required. You can test EF-x or even poll the status register.

Programming hint.  To read only one sector without TC all that is needed is when writing
command string  is that the start sector is equal to end sector.  It will complete with end
of track(not really an error).

FYI the number of commands actually needed are less than 100%, some are really not that useful.
as a result its possible to create simpler software.

BTDT, have the full outfit on multiple CPUs.

Allison

Elf2k V88 needs Terminal Local Echo set to ON

Rizal Acob
 

Just burned V88 into eprom and replace the V87 ROM in the Elf2k...noticed that I have to turn ON the local echoing to see what I type on the screen. Can someone confirm please that this is so. Thanks

Todd's ELF-ish to get an FDC #Homebrew #microboards

taf123
 

Back in July, in the crazy topic "Okay, let's get really crazy...", https://groups.io/g/cosmacelf/topic/32570650, there was a discussion about the RCA CDP18S651 Microboard Floppy-Disk Controller.  This got me interested in a the idea of building a clone of that card for my ELF-ish project.  However, as was pointed out then, a large number of the components are dedicated to the data separator, which also required some rather critical adjustments, and there are dedicated chips to do this sort of thing.

Initially, I looked at the FDC9229BT which does the data separator and write precomp function and directly supports the FDC765.  But then I found the FDC9266 , which is basically both of these combined. And conveniently for me, a UK based eBay source.

This radically reduced the component count, removed the critical adjustments, and brought the project into the scope of something reasonable to build.

Another aspect of the CDP18S651was the support for the various floppy interfaces of the time.  But in the post-PC world, the interface is now fairly standardized unless you want to go for some rather vintage drives.  So I decided to cut out all of the unrequired drive interface support stuff.  The simplified drive interface is based upon the example FDC design on page 24 of the 1979 application note on the uDP765, which I found as uPD765_App_Note_Mar79.pdf on bitsavers. There is support for up to four drives using two PC-style 34-pin IDC interfaces.

I replaced the single motor-on flip-flop with a 74HC175 Quad D-Type Flip-Flop to give separate motor-on control for each drive.  Although I added a jumper to allow both drive 0 and 1 to be controlled by the same motor-on bit to be compatible to the original.

I also dropped the full-support of the RCA two-level I/O system and just hard-wired Group-8 (or IO4 in my ELF-ish world).  I used the now spare 1/2 4013 flip-flop to latch the state of BUS3 during an OUT 1.

I also allowed a jumper option to connect to the IR7 level of the CDP1877 Programmable Interrupt Controller back on the CDP-IO chassis.

I also like the idea of being able to read the control latches, so I added a 74HC244 3-state Octal Buffer controlled by the previously unused INP 7.

And I use a DIL-8 8Mhz can oscillator rather than a crystal.

The complete schematic has been uploaded to https://groups.io/g/cosmacelf/files/Todd%27s%20ELF-ish%20Schematics as ELF-BB-FDC-II_20191124.pdf.  It's "-II" as it's my second attempt at a design, the first having been closer to the RCA original.

Here's the planned layout.



Now I just have to build it.  I'll keep the forum posted on how I get on.

I would appreciate reading any comments, thoughts, or suggestions on the design.

Share and enjoy,
Todd

New file uploaded to cosmacelf@groups.io

cosmacelf@groups.io Notification <cosmacelf+notification@...>
 

Hello,

This email message is a notification to let you know that the following files have been uploaded to the Files area of the cosmacelf@groups.io group.

Uploaded By: taf123 <todd.ferguson@...>

Description:
Floppy-Disk Controller originally based upon the RCA CDP18S651 then heavily modified.

Cheers,
The Groups.io Team

Re: Todd's ELF-ish gets some more I/O #ELF #Homebrew

taf123
 

For those interested, I've uploaded the current versions of the Main and CDP-IO schematic files to https://groups.io/g/cosmacelf/files/Todd%27s%20ELF-ish%20Schematics

New files uploaded to cosmacelf@groups.io

cosmacelf@groups.io Notification <cosmacelf+notification@...>
 

Hello,

This email message is a notification to let you know that the following files have been uploaded to the Files area of the cosmacelf@groups.io group.

Uploaded By: taf123 <todd.ferguson@...>

Description:
Updated versions of Todd's ELF-ish schematics for the Main chassis and first expansion Chassis

Cheers,
The Groups.io Team

Re: Todd's ELF-ish gets some more I/O #ELF #Homebrew

taf123
 

The final update has to do with the two-level I/O system.  Sub-routines and Interrupt Service Routines shouldn't leave any unwanted side-effects.  For processing I/O, this means they should set the I/O-level back to whatever it was before they select a new I/O-level to process whatever it is they need to I/O.

With the two-level system as built, it's write-only.  To achieve the required transparency, all I/O processing would need to save the I/O-level into a well-known memory location so sub-routines and ISRs could reset it when they were finished.

I don't like this option.

Using the last of the freed up space from the RTC rebuild, I installed a 74HC244 3-state Octal Buffer which simply reads the current state of the I/O-level as set in the CDP1875 output port I'm using as the I/O-level latch and sends it to the buffered I/O-bus.  This is connected to the previously unused INP 1 (69) command.  Now sub-routines and ISRs can use INP 1 to read the current I/O-level, store in a temp location, do their thing, and then reset I/O-level by outputting the stored value.





You'll note that I'm not using the full complexity of the RCA two-level system.  Instead, I just use each bit as an individual selector, giving eight I/O levels, labelled IO0 - IO7.

For a quick test of this, I set bit 2 of the I/O level (IO2) by outputting 0x04. This I read back in using the new support for INP 1. I then changed the I/O level so bit 0 was set (IO0), enabling the HEX displays, and output the previously read 0x04 to the display.



This picture also captures all of the recent changes.

Re: Todd's ELF-ish gets some more I/O #ELF #Homebrew

taf123
 

Next up was to fix the hack I had to use to get the AMD 9511 APU working. As a reminder, the AMD 9511 requires the !MRD signal to be delayed until after the low byte of the address has stabilized on the multiplexed address bus. I was limited to existing spare gates on the board, so I used the combined propagation delay of several gates. This worked, but was a terrible hack.

Using some of the freed up space by removing the RTC discreet oscillator, I was able to rebuild this.



I installed a 74HC74 (U42) dual D flip-flop and a 4011 (U34) quad two-input NAND. Using this, I created the delay synchronously to the clock and system timing pulse TPA.

I invert TPA, so the trailing edge clocks FF A and sets its Q. The output of this is connected to the D-input of FF B. On the next raising edge of the system clock, this sets the Q, and clears the !Q of FF B.

The !Q of FF B does two things. First, it clears the FF A, resetting it until the next machine cycle. It also sets the RS FF made up of two of the NAND gates, the output of which I've labeled WINDOW.

WINDOW is then gated with MRD (inverted !MRD), to provide a delayed !MRD (!DMRD) for the APU.

At the start of the next machine cycle, the inverted TPA signal resets the RS FF and the cycle repeats.

Phew. But does it work?




Since the APU is memory-mapped, I can operate it directly from UT4. This is the same test I performed before where I add the two 16-bit numbers 0x1234 and 0x5678).

The first four lines push the four bytes onto the APU internal stack. The fifth line issues the 16-bit add (0x6C).

The next lines pops the resulting two bytes off of the APU internal stack. The result is 0x68AC, which is correct.

The final two lines reads the APU status register. Value 0x00 means that the APU is currently idle and that the previous result did not cause a carry/borrow.

So it works. Yeah!


I wanted to look at the signals in detail, but that £18 logic analyzer I have been using, operating at only 8Mhz, just doesn't give good enough results (or at least I wasn't happy with them any more).  So I got an upgrade - a Kingst LA5016 USB 16-channel Logic Analyzer with a 500MHz sampling rate.  This cost £132 (about $160) on eBay from China.



This comes with its own software, which is quite a step up from the sigrok I was using with the other system.






The screen shows the read of the APU status register at 0xCC01. The ten channels were connected as follows:

00 - CPU Clock
01 - TPA
02 - TPB
03 - !TPA
04 - D1TPA
05 - !D2TPA
06 - WINDOW
07 - !MRD
08 - !DMRD
09 - APU !CS
10 - MA0

The green vertical lines are measurement pairs, with the results in the box on the right.

The difference between B1 & B2, the left pair, is the fetch machine cycle of eight CPU clock cycles.  With my manual placement, the results showed 3.254us, which is close enough to the 3.255us from a 2.4576Mhz CPU clock.

The middle pair, A1 & A2, shows the amount that !MRD has been delayed (!DMRD) compared to the transition of MA0 to the HIGH state, which is 166ns.

According to the ADM 9511 datasheet, TCDR, C/!D (connected to MA0) to !RD LOW set up time, must be at least 0ns (!RD must happen after C/!D is stable, not before).

Looks good.  I didn't measure the actual delay achieved between !MRD and !DMRD, but it looks about 1.5 CPU clock cycles.

Re: Todd's ELF-ish gets some more I/O #ELF #Homebrew

taf123
 

I like the idea of generating the baud clock for the CDP1854 UART from the CPU clock - it seems to go along with the COSMAC philosophy of component reduction.  But, there are times when I'll want to change the CPU clock, but still want to use the UART, so I have to decouple this.

Using the space freed up by removing the RTC battery backup, I installed a DIL-8 2.4576Mhz can oscillator.

Re: Todd's ELF-ish gets some more I/O #ELF #Homebrew

taf123
 

The next change has to do with the CDP1879 Real Time Clock.  The discrete 32.768kHz oscillator had some problems; it's not accurate enough, the frequency would shift with the lower voltage during battery backup, and it eats the cell batteries I was using.

To "fix" all of this, I replaced the discrete oscillator with a DIL-8 can oscillator and removed the battery backup components.  In addition to fixing the accuracy of the clock, this also frees up much needed space on the board for the other changes I had in mind.

Of course it means I don't have battery backup for the RTC any more, but I may go back and fix that at a later date.

Re: Todd's ELF-ish gets some more I/O #ELF #Homebrew

taf123
 

I've decided to make some changes to the ELF-ish before working on additional expansion.  Firstly, I changed my mind about POR into the monitor vs. RUN_U/RUN_P.  I've decided that I prefer RUN_U/RUN_P but that there are occasions when I'd like to be able to POR to monitor in VIP style.  So, I decided to allow both, using jumpers to select the method.

So I rebuilt the RESET latch and the RUN_P de-bouncer, but added an additional jumper, JP7, which can disable the latch to allow the POR into monitor function.  The DS1233-10 is still in place so in either mode, we still have POR.



Back on the main chassis, I had to bring the RUN_U signal back to the RUN_MODE jumper to allow the selection between RUN_U/RUN_P and VIP style jamming for the monitor at 0x8000.


Re: Frequency Limit of CDP1802ACE and 1806 ACE #MembershipCard

ca1naj610
 

All:
More experimentation on high frequency operation follows:
In order to be able to swap out CPUs, EEPROMS and crystals,  I fabricated a prototype board with ZIF sockets and machined sockets for the crystals. 
Since many members appear to be mostly interested in a nominally 5VDC supply and since only the 1802 is compatible with LOAD mode, this study
only looked at CDP1802 chips.  Evaluating fifteen of them yielded the following frequency limits:
1802CE RCA 919                  6.14MHz
1802CE RCA 218R                6.14MHz
1802CE RCA 919                  8.00MHz
1802AE RCA X 336               8.00MHz

1802ACE Intersil H0745        14.40MHz
1802ACE Intersil H0745        10.00MHz
1802ACE Intersil H0745        12.00MHz
1802ACE Intersil H0745        14.40MHz

1802ACE Harris J9128         14.40MHz
1802ACE Harris J9132          12.00MHz
1802ACE Harris J9506          14.40MHz
1802ACE Harris J9414         14.40MHz
1802ACE Harris Z027           14.40MHz  (Remarked)
1802ACE Harris Z027           8.00MHz   (Remarked)
1802ACE Harris J9429         16.94MHz

The four old RCA chips averaged 7.07MHz
The four Intersil chips averaged 12.70MHz
The seven Harris chips averaged 13.51MHz
Vcc = Vdd= 5.13VDC    The oscillator was the crystal and a 1 M Ohm resistor connected between pins 1 & 39
Only three ICs were implemented (no RAM).  I used a 28C256 EEPROM containing a modification of Lee Hart's slow Q blink program which resides in page 0 and page 1
and 74HC373 for decoding the address high byte.
Yes, there is variation among chip type.  Actually, I am surprised at how fast the old 1802CE chips are.  The worst CE chip worked at 6 MHz.  The weighted average for the ACE chips is 13.21 MHz.
So I can be quite confident that any randomly selected 1802ACE chip of mine should work way above 5.00MHz and for the old CE chips, 5.00 MHz should not be a problem.
The concern about multipage memory seems not to be an issue since this study is not inconsistent with my earlier work. 
Perhaps the possibility of TPA shift is mainly theoretical below 14 MHz for ACE ICs.  Maybe I just happen to have remarkably capable 1802s. 
Maybe the TPA shift is problematic for the old CE chips?  Further work will include writing to memory as well as multipage memory programming.

My purpose in all this evaluation is for my earlier concern over operation above 3.2 MHz.   I no longer am apprehensive about clock frequencies up to 10 MHZ as long as
I work at nominal room temperature.  I have not found any heat buildup in the CPUs (finger touch).  If other members find this experimentation useful, it is my treat. 
Many thanks to all who have provided critical concerns.  Their comments made me think more thoroughly about operation of CDP1802 ICs at higher frequencies.
Denny

Altaid 8800 #MembershipCard

joshbensadon
 

Hi Greg,

I'm starting a new thread for this topic.  Helps to keep organized.

>Lee's Altaid 8800 switches and LEDs,  Amazing!

Yes, I have a prototype unit built using some of the new bright LED's... wow, it looks like candy to me!
 
>may be sacrilege, but if worse comes to worse, Altoids-like metal tins are available in a slew of sizes slightly larger than the Altoids real deal.

Sacrilege, lol!  Yes, thanks for the reminder.  I once commented that if he could do this in an Altoids box, there's no end to what he could do if he had a cookie tin!

I do agree with you, there's probably a lot more that can be done if he went to a bigger size.  Imagine the computer he could build if he had to fill an entire ALTAIR 8800 box?
Even the good folks at MITS must have thought the ALTAIR was too big... their next computer, the ALTAIR 680 became much smaller, "The small wonder of the micro-world".

If he did want to go bigger, your alternatives are definitely a good place to start, but there are more choices.  Lots of project boxes available in any size.  I really like the ones where they have PCB guides... I keep thinking that would make an excellent box for a back plane.  Search Digikey boxes, they have a features filter called "Cards" that narrow the search to boxes with these card guides.  A setup of pin headers and sockets (like the Heathkit H8) would keep costs low.. unless edge card connectors can be cheaper?? I don't know.

Besides cost of bigger boxes, I think Lee's biggest reason to squeeze it into Altoids is for the novelty.  Well, in the case of the Altaid, it's a clever name. But aside from this project, it's just the cuteness and popularity of this tin!  One of his data sheets includes voltage, current and scent!  He wasn't the first or only person to get attracted to this box.  I think there are many small radio projects that were fitted into this box because of it's shielding property.  

Of course, we are all just overlooking the obvious.  Perhaps Lee just has an addiction to mints?
There's nothing wrong with this.  Lee, I understand and accept you just the way you are!
If you want, you can always get help from Altoids Anonymous?

Regards,
Josh Bensadon







 

Re: RCA MCDS Tape I/O Board Question

Lee Hart
 

gregory simmons via Groups.Io wrote:
Lee, I just noticed that, as you said, your Altaid 8800 does have
switches and LEDs, which the N&V Altaid does not. Amazing!

Also, and this may be sacrilege, but if worse comes to worse,
Altoids-like metal tins are available in a slew of sizes slightly larger
than the Altoids real deal.
Yes, I've seen quite a few styles in the hobby & crafts market. Candies, cookies, and all sorts of things are packed in them. They certainly make sense for a one-off project. But they lack the universal availability of the Altoids tin. If that brand isn't handy, there are a dozen competitors in exactly the same size.

After all, sometimes it's just not possible
to put 10 lbs of **** into a 5 lb bag.
Sure it is... you just need a big enough hammer. :-)

Actually, we do our best work when challenged. Great art can be produced from nothing but a piece of canvas and some home-made paints and brushes. Great music from just a guitar. And great stories with just pencil and paper.

There is no challenge; no skill; no innovation to solving problems with massive overkill. That doesn't take brains, just mindlessly plodding straight ahead.

So I set deliberate limits for myself. What can I put in an Altoids tin? How few parts does it take to accomplish a given task? It's harder... but more fun!

Lee

--
To invent, you need a good imagination and a pile of junk. (Tom Edison)
--
Lee Hart, 814 8th Ave N, Sartell MN 56377, www.sunrise-ev.com

Re: Emma 02 - V1.33 #Emulator #microboards #mcds

Marcel van Tongeren
 

Hi Marc,

Thanks for the nice comments!

I do want to mention (in case you don’t know) that I ‘cheated’ and used Mike’s 1802 emulator code as a starting point. So that gave me a kick start for sure. Of course I did add quite a lot of machines and features since.

When I started I was also not aware of all machines on the 1802; we had a COMX 35 ourselves and I had heard about the Elf and the Cosmicos but nothing else.

Cheers, Marcel