• Please review our updated Terms and Rules here

Is there an RX01 Emulator?

jackrubin said:
I must not be holding my mouth right - I tried several things - I downloaded your example, I went back and re-edited my file, I downloaded your first example when Mark had this problem, I even reloaded Ardruino 1.6.8, all with no success and the same error stating 'class HardwareSerial' has no member named 'printf'.

????

Jack
Click to expand...

Is the file Print.h you are dealing with in this directory: "C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino"

If so, then I don't understand why you are getting this problem. I have replaced the Print.h file in this directory on multiple systems (all Win7, however) over multiple Arduino IDE versions (all 1.6.x however, I have not updated to 1.8.x yet).

I checked, there is only one Print.h file under the whole Arduino install hierarchy in 1.6.13. I'm wondering if under 1.8.0 there is more than one Print.h, since the new release purportedly adds support for other Arduino architectures, and maybe you are not modifying the correct one?

Don
 
Last edited:
I am not an arduino expert by any means :)!

The error report from the compiler is stating that it can't find the method printf in the HardwareSerial class. The code addition seems to be adding a method called printf to the class Print.

I was having a quick 'wander' through the source code for these classes/methods - but can't see where the classes HardwareSerial and Print 'combine' so that the added 'printf' becomes a member of Hardware Serial (but I have only had a quick look).

If there are multiple versions of print.h - the best way I have found to see if the version you think is being used is to deliberately introduce a syntax error into the file you are expecting the compiler to use (say adding XXXXXX somewhere where (say) a type is expected). If no errors result when you compile the program - then that instance of the file is not being used...

Dave
 
Curiouser and curiouser - I've done a complete un-install/re-install of Arduino 1.6.8, using the default options and verifying that the modified Print.h file is located at C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino.

I get the same error - specifically, during the Verify phase, line 1360 of rx0_driver.cpp is flagged for 'class HardwareSerial' has no member named 'printf'.

In the same ...\cores\arduino\ directory, line 134 of HardwareSerial.h says "using Print::write, so it seems that Print is referenced.

What's more curious is that renaming Print.h to noPrint.h, HardwareSerial.h to noHardwareSerial.h and HardwareSerial.cpp to noHardwareSerial.cpp doesn't change anything when I attempt to verify/compile/run rx02_emulator.ino. In fact, if I mess with Don's project code - changing rx02_driver.cpp to no-rx02_driver.cpp - the IDE merrily incorporates the renamed .cpp file and proceeds to generate the same error.

I've also tried placing the modified Print.h file in Don's project file to no avail.

What seems to be missing is some master "make" file that would actually recompile all the .cpp files using the changed .h files. Even though Arduino says it is doing a "verify/compile" of the sketch, it just seems to be sucking up pre-compiled reference files.

There has to be a giant REDO button somewhere that I'm missing due to my lack of Arduino knowledge.

BTW, I'm running all this on a Win7 Enterprise, Service Pack 1 machine. Next, I'll give it a try on my Win10 laptop.

Jack
 
I see the 'using Print::write' that you have identified - although this only makes the multitude of 'write' methods located within class print available to class HardwareSerial at this point.

I think you are on the right lines with your 'if my library source files change - how do they get built' question (my interpretation)...

There should be some sort of build file that came with the arduino release (or did you use a pre-compiled variant and not build the libraries yourself?)

Dave
 
Major step forward - I found the relevant files in C:\Users\Jack\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.6.15\cores\arduino, probably because I used the Windows installer. I set the compiler to verbose and am now able to see recompile notices and file references.

I see that Arduino is doing a recompile and referencing these files. I'm getting a different error right now but I'm going to go back and do the "non-admin" download and install to try to get on the same (literal!) page as Don and Lou.

More later -

Jack
 
jackrubin said:
Major step forward - I found the relevant files in C:\Users\Jack\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.6.15\cores\arduino, probably because I used the Windows installer. I set the compiler to verbose and am now able to see recompile notices and file references.

I see that Arduino is doing a recompile and referencing these files. I'm getting a different error right now but I'm going to go back and do the "non-admin" download and install to try to get on the same (literal!) page as Don and Lou.

More later -

Jack
Click to expand...

Very strange. In that directory (C:\Users\Don\AppData\Local\Arduino15\) all I have are these files: library_index.json, package_index.json, package_index.json.sig, and preferences.txt. No other files or folders.

Maybe there is some install option you selected at one time (now flagged in the registry?) that says to put data files under your AppData directory rather than under ProgramFiles?

If I go and edit my Print.h file and comment out the added code, I can recompile immediately and get the same error that you do (printf missing from HardwareSerial class). Undo the comment block and recompile, and it compiles successfully again.

The \1.6.15\ in your path also seems strange to me ... to my knowledge 1.6.13 (what I have now) is the latest/last 1.6.x version.

I assume you are getting your install files from here: https://www.arduino.cc/en/Main/Software

Are you doing the windows installer but not doing an Admin install? Maybe that causes compiler data files to be put under Users/... ?

Don
 
I dropped back and did a manual install, deleted old folders in ../Local/Arduino15, cleared out the Arduino file in Temp, deleted most of the last sketch and last screen info in the preferences file, installed SDFat and modified Print.h, etc.

I got a compile with a bunch of warnings about unused and uninitialized variables and a good upload:
'Sketch uses 34962 bytes (13%) of program storage...'
'Global variables use 2174 (26%) of dynamic memory...'

The shield isn't connected to my controller and the SD card is blank. Led D1 on the board lights, the board sends out status data, detects and validates the SD card, sets up the .DSK files, signals that initialization is complete and then D1 goes out.

Looks like my Arduino and your code have reached an understanding. Now I've got to load some images, hook it up to my 8/M and see what else it can do.

Thanks to Don and Dave for your help!

Jack
 
With the latest (v1.6) software on github I see these stats after compiling:

Sketch uses 36,262 bytes (14%) of program storage space. Maximum is 253,952 bytes.
Global variables use 2,573 bytes (31%) of dynamic memory, leaving 5,619 bytes for local variables. Maximum is 8,192 bytes.

So what you are getting (probably from a bit older software) is about right.

Startup behavior is correct. INIT led (red) will light at startup, and clears when INIT is deasserted by the host interface, or after 10sec, whichever comes first.
The red LED will light whenever INIT is asserted, and whenever the emulator detects an error and asserts the ERROR line. A new function clears the red LED (and error).

Yellow LED lights whenever the SDcard is actively being accessed, off when SDcard is idle.

Green LED lights whenever a command function has been initiated, goes off on command complete (ie, DONE asserted).

Normal behavior will be Green LED flashing during commands, possible Yellow LED flash during SDcard read or write.

Sometimes Red LED will flash when host decides to do a programmed INIT (via the register bit).

Don
 
Last edited:
jlang said:
It seems I'm late to this party... Does anyone have a ds8641 bare board they would like to sell?
Click to expand...

For anyone interested, I still have (as of this date) about 15 of the latest 2N7000 based design bare fabs (ENIG) and about 10 of the 8641 based design bare fabs (ENIG).

I also have about 15 of the microSD card breakout board adapters (sourced from SparkFun).

Cost is $10 each for the bare PCB plus $2.50 shipping (domestic US). SparkFun microSD adapter boards are $5 each.

So the party is still going, you are not too late. Send me a PM if interested.

Don
 
I'm happy to report the rx02 emulator has been tested on rxv11 emulating RX01. Works exactly as advertised!

I built a bootable RT11 5.3 image on simh then copied it to the sd card. I couldn't get it to boot... Then I RTFM
image has to be exactly 256256 bytes. After I fixed that It booted right up.
I then:
init dx1:
copy/sys *.* dx1:

Worked great! It's just as slow as I remember RX01 to be ;-)

joe
 
jlang said:
I'm happy to report the rx02 emulator has been tested on rxv11 emulating RX01. Works exactly as advertised!

I built a bootable RT11 5.3 image on simh then copied it to the sd card. I couldn't get it to boot... Then I RTFM
image has to be exactly 256256 bytes. After I fixed that It booted right up.
I then:
init dx1:
copy/sys *.* dx1:

Worked great! It's just as slow as I remember RX01 to be ;-)

joe
Click to expand...

Good to hear. RX11/RXV11 mode was one that I am unable to test myself (I only have RX02/RX211, RX01/RX8E, and RX02/RX28 configurations).

As to speed, by default the rx02 emulator s/w uses the 'as fast as possible' timing mode selection (t 0) so there are no implicit delays added to any accesses to simulate track seek delay, sector access rotational delay, or data access delay. If you want to see what using a 'real' rx01 would be like, set timing mode to '2' (t 2) to insert these additional delays that simulate accessing a real rx01/rx02 device.

Yes, SIMH does not extend simulated device image files to the full size of the device (it only extends if the blocks are written). So disk images made on SIMH (or even imported from other tools) may not be exactly 256,256 bytes (RX01) or 512,512 bytes (RX02).

My rx02 emulator s/w first used only the file size to detect the image type, and this worked to a point. There are manual intervention menu commands that I implemented to block out files to the RX01 or RX02 image sizes to help mitigate the issue (ie, zero extend or truncate).

More recently I added specific file extensions (.RX1 and .RX2) to flag an image as that type, and not just use image size as the detection parameter.

So a filename with .RX1 extension will be truncated/extended to 256,256 bytes and forced to be RX01 formatted.
A filename with .RX2 extension will be truncated/extended to 512,512 bytes and forced to be RX02 formatted.

Any other filename extension (like .DSK, .IMG, etc) will cause the filesize to be examined, and it must be either 256,256 (exactly) or 512,512 (exactly) bytes to be interpreted as an RX01 or RX02 image, respectively. Other sizes will not be able to be mounted.
 
Last edited:
What controller card are you guys using for your RX02 emulator? I bought a RXV21 last week, version ‘C’. I am building a little 4 card PDP11 dual card width system. I want to use the AK6DN emulator for a drive. I have both an 11/23 and 11/73 processor. I read on the chdickman.com site that I need a revision ‘D’ or greater to run on the 11/73. Is that true? Are there mods I can make to my version ‘C’ controller to get it to work with an 11/73?

Cheers,

Len
 
8008guy said:
What controller card are you guys using for your RX02 emulator? I bought a RXV21 last week, version ‘C’. I am building a little 4 card PDP11 dual card width system. I want to use the AK6DN emulator for a drive. I have both an 11/23 and 11/73 processor. I read on the chdickman.com site that I need a revision ‘D’ or greater to run on the 11/73. Is that true? Are there mods I can make to my version ‘C’ controller to get it to work with an 11/73?
Click to expand...

You referenced both version and revision in referring to the RXV21 so I guessing that the board is Etch C and you have many wire wrap jumpers as illustrated on the chdickman site. The revision level refers to modifications to the boards - such as jumpers or etch cuts, typically burned on the handle solder side.

Confirming the correct etch / rev on the boards would be the best place to start. Then you decide if you want to manually apply the fixes from the maintenance print or other sources.

There are references to semiconductor problems on earlier cards (original unotes #92). The nature of this is not detailed in the note, so I am not sure what the problematic component is. The other fix refers to incorrect DMA Bus Address incrementation over 32KW boundaries (notes #104). The latter is critical if you are using an >32KW of memory. This "MAY" be the reason for the revision F or greater for 11/23 and 11/73. For RT11SJ, SB or FB you would not need this particular fix.
 
Thanks wa2flq,

That helps somewhat. Yes, etch level C. I do have a lot of blue patch wires on the board. Although I can't see a revision level inscribed anywhere. Does anyone have an example that I can see what I am looking for?

73,

len

wa2flq said:
You referenced both version and revision in referring to the RXV21 so I guessing that the board is Etch C and you have many wire wrap jumpers as illustrated on the chdickman site. The revision level refers to modifications to the boards - such as jumpers or etch cuts, typically burned on the handle solder side.

Confirming the correct etch / rev on the boards would be the best place to start. Then you decide if you want to manually apply the fixes from the maintenance print or other sources.

There are references to semiconductor problems on earlier cards (original unotes #92). The nature of this is not detailed in the note, so I am not sure what the problematic component is. The other fix refers to incorrect DMA Bus Address incrementation over 32KW boundaries (notes #104). The latter is critical if you are using an >32KW of memory. This "MAY" be the reason for the revision F or greater for 11/23 and 11/73. For RT11SJ, SB or FB you would not need this particular fix.
Click to expand...
 
8008guy said:
Thanks wa2flq,

That helps somewhat. Yes, etch level C. I do have a lot of blue patch wires on the board. Although I can't see a revision level inscribed anywhere. Does anyone have an example that I can see what I am looking for?
Click to expand...

Hi Len,
Below is an image of the revision stamp on the board. This is a Etch D (outside of this image on the right), Rev F RXV21.

RXV21 Rev F.jpg

Jerry
 
8008guy said:
Jerry,

Perfect! The company I bought the card from put their inventory tag over the revision stamp. Mine is an E. Is that up to date enough to run on an 11/73?

Len
Click to expand...

According to micronote #104, the address register doesn't increment across 32KW boundaries correctly in Rev E and lower. So an 11/73 using less than that amount of memory should work (see my earlier comment on viable types of RT11). Trying to address more memory that and the IO will likely overwrite/overread unintended memory addresses which could lead to crashes or data corruption. The system can have more than 32KW of memory, just don't try to use it with the floppy.

Its not immediately clear from the maintenance print what the specific changes are from E to F.

Another think to note about the RXV21 is that it has only 18 bit addressing. So use of more than 128KW of memory (22 bit system) requires a bit of extra work even for a Rev F or greater. Some OS'es have handlers or patches for them that will buffer the IO in the lower memory and use CPU cycles to move data between higher addresses to work around the problem.

Jerry
 
Cool, thanks for your help.

len

wa2flq said:
According to micronote #104, the address register doesn't increment across 32KW boundaries correctly in Rev E and lower. So an 11/73 using less than that amount of memory should work (see my earlier comment on viable types of RT11). Trying to address more memory that and the IO will likely overwrite/overread unintended memory addresses which could lead to crashes or data corruption. The system can have more than 32KW of memory, just don't try to use it with the floppy.

Its not immediately clear from the maintenance print what the specific changes are from E to F.

Another think to note about the RXV21 is that it has only 18 bit addressing. So use of more than 128KW of memory (22 bit system) requires a bit of extra work even for a Rev F or greater. Some OS'es have handlers or patches for them that will buffer the IO in the lower memory and use CPU cycles to move data between higher addresses to work around the problem.

Jerry
Click to expand...
 
You must log in or register to reply here.
Back
Top