Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - netfreak

Pages: [1] 2 3 ... 19
Computing, Internet & Technology / Vintage Computing Wiki
« on: June 27, 2019, 03:46:27 pm »
The wiki ( is now working at acting primarily as a source for vintage and retro computing topics. We've also created a single wiki article linking to a number of outside resources:

Off Topic / Nathan Kunkel - scammer
« on: May 13, 2019, 04:53:42 pm »
Almost forgot about this one. Ripped me off to the tune of $300 and I suspect there were others. Operation was based out of Kelowna, BC, Canada.

Here's an interesting problem... If you have a VM behind a Sophos UTM (or other firewall such as ASA) on a VMware ESXi 6.x host using be2net Emulex driver but you get an error 400 (bad request) when trying to browse external sites, the be2net driver itself might be somehow stripping the HTTP headers. We logged this invalid request:

xx.xx.xx.xx - - [31/Dec/2018:16:49:49 -0800] "\x00\x00\x00\x00\x00\x00" 400 166 "-" "-"

This was the case with the following driver configuration:

driver: be2net

A solution was to revert back to the elxnet driver. We ran into issues on this driver in the past which led us to enabling be2net originally (ESXi 5.5 and IBM OEM image). So if you're running into this issue under ESXi 6.x with the IBM/Lenovo OEM image on an HS23 blade, do this:

esxcli system module set --enabled=false --module=be2net
esxcli system module set --enabled=true --module=elxnet

Reboot your host and re-test.

Off Topic / VerticalResponse Inc spammer activity
« on: July 09, 2018, 01:46:17 pm »
This company VerticalResponse Inc doesn't care about spam abuse and will keep blasting you with unwanted mail while ignoring abuse complaints. I suggest you nullroute their network.

NetRange: -

Off Topic / ignores spammers on their network
« on: June 01, 2018, 10:54:14 am »
I suggest sysadmins null route the IP blocks advertised by as they let spammers run on their network. Here is the result of a recent spam complaint against them:

Code: [Select]

Thank you for contacting us! This is an automated message to let you know we've received your request. We assure you that we investigate each and every abuse report we receive, and will take the appropriate action. To provide us with more details and updates, please include the ticket ID in the subject line. We take your request very seriously and will perform a thorough investigation, which can take up to 48 hours, to ensure issues are properly resolved.
Ticket details:

Ticket ID: [tt #3233579]
Subject: [SpamCop ( id:6818358810]Tradebay offers to partner up and ..
Status: new

Kind regards, Abuse Team

Code: [Select]

As our customer informed us, this wasn't spam but their direct marketing offer.

Regards, - Abuse is a joke.

Off Topic / Nova Scotia premier Stephen McNeil is a dipshit
« on: May 10, 2018, 06:39:57 pm »

His government puts private data out in a public website and then arrests someone for accessing it. This dumbass still thinks he's in the right and will probably never learn how the Internet works.


I ran into this error trying to run setenv on my SGI Indy to a MAC within the standard SGI pool 08:00:69:x:x:x as I suspected this is why my onboard ec0 network adapter was not visible in IRIX. Turns out the MAC shown was for a secondary network card in the system (ec2) and it was causing IRIX to throw an invalid MAC warning during boot.

I'm not sure if there's a way around this in order to keep the second NIC in the system, but I simply removed it which allowed ec0 to show up in IRIX again. No more invalid MAC warning during boot and I could throw an IP on ec0 and ping things.

General Chat / Higher Intellect Blog
« on: October 08, 2017, 09:57:01 am »
A new area on the site is our blog located at

It'll focus mostly on computing topics and likely many will be retro/vintage computing related. Site updates and news about will also be posted.

So I've got a no-name socket 7 Pentium board with the ID string 07/04/97-VXPro+-USB-Ultr-2A5LDH09C-00 and I needed to update the BIOS due to a 32mb limit per SDRAM slot. I still don't know the manufacturer of my exact board but it looks VERY close to the PC Chips M537 which has the same VXpro chipset. I think the only visible difference is some chips are in different spots on the board. I decided to take the risk of flashing the PC Chips M537 BIOS update onto my board, and so far it seems like everything still works plus I've got all my SDRAM showing up now. Here's how to do it:

1) Download which is the BIOS image I used.
2) Also download which includes the AWDFLASH.EXE utility plus a backup of the original board BIOS
3) Ensure your board jumper setting allows for flash update
4) Create a DOS boot floopy with the PC Chips M537 BIOS and AWDFLASH.EXE application. I just used a Win 98 boot disk and deleted the non-critical stuff to make enough space.
5) Boot and run the AWDFLASH.EXE application. Enter the new BIOS image from the PC Chips zip file when prompted. You can also make a backup if you want. You'll get an error about the BIOS ID strings not matching and this is expected since the board is not a PC Chips board. Assuming you're brave, continue with the flash. Reset when complete.
6) If the system seems to lock up during POST, reboot again and hit Del to get into the BIOS settings. Choose the option to set everything to BIOS default and save/reboot.
7) Assuming step 6 worked, go back into BIOS settings and enable everything you need.

I'm not sure specifically what setting the PC Chips BIOS didn't like, but I re-enabled all the options I recall being enabled on the original BIOS and haven't had any issues with lockups. The PC Chips M537 archive I link to is I believe a 1998 firmware image. I don't know the full change history but it does support my 256MB SDRAM and possibly large HDs (well, large for that era). Also I've heard even though the board has USB it won't work since the standard changed during manufacture. I set mine to disabled in the BIOS.

Off Topic / 226-316-1458 scammer
« on: July 18, 2017, 11:18:28 am »
Ignore calls from this loser. The guy on the voicemail sounds angry like he can't please his wife with his tiny package. Probably some 400lb sack of crap too.

Off Topic / DS 3501 Jack Northrop Ave scammers
« on: July 15, 2017, 10:34:10 am »
These scammers send you notices which appear to be domain registration expiration notices in an attempt to fool people. If you receive e-mail from these idiots, report their ISP for spam.

"By accepting this proposal, you agree not to hold DS liable for any part. Note that THIS IS NOT A BILL. This is a solicitation. You are under no obligation to pay the amounts stated unless you accept this proposal. The information in this letter contains confidential and/or legally privileged information from the notification processing department of the DS 3501 Jack Northrop Ave. Suite #F9238 Hawthorne, CA 90250 USA, This information is intended only for the use of the individual(s) named above. There is no pre-existing relationship between DS and the domain mentioned above. This notice is not in any part associated with a continuation of services for domain registration. Search engine submission is an optional service that you can use as a part of your website optimization and alone may not increase the traffic to your site. If you do not wish to receive further updates from DS reply with Remove to unsubscribe. If you are not the intended recipient, you are hereby notified that disclosure, copying, distribution or the taking of any action in reliance on the contents of this letter is strictly prohibited."

Off Topic / Austin Strickland is today's piece of shit
« on: June 27, 2017, 09:26:54 pm »

Only in Florida I guess. Along with the witch hunt on Facebook spread by dumb ass fucktards, I'd say Austin Strickland is today's piece of shit. Congrats on making the rest of us want to completely ignore children in need of assistance. Maybe try being a better parent you goddamn loser.

Gaming & Entertainment / DukeEdit readme
« on: February 18, 2017, 04:45:14 pm »
Thanks for taking the time to evaluate DukeEdit, the only level editor for Duke Nukem 3DĒ currently available on the Macintosh (so far as I know).

System Requirements:
   System 7 or better.  It has been tested with Mac OS8 and works fine.
   68040 or better.  It has not been tested on anything lower than this.
   Power PC recommended.
   2 MB of RAM is the absolute bare minimum.  4 MB is suggested, 8 MB is recommended.
   256 Color graphics is recommended.
   It will run with fewer colors, but you probably won't like it.
   Takes less than 1/2 MB of hard disk space.
   Duke Nukem 3D must be installed on your system to use this product.
   In order to make your own maps, you will need the commercial version of DN3D.
   With the shareware version, this product can be used only as a map viewer.

DukeEdit was created on a Power Mac 7500 using CodeWarrior 12, AKA CodeWarrior Professional Release 1, and is available in both 68K and Power PC versions.  The Power PC version is native.  I am not convinced anyone is interested in a 'fat' version; i.e. a single version that supports both Power PC and 68K.  If you wish to receive a fat version, please contact the author at the e-mail address given below or write to him at the address used to register the product, also given below.

Software Contents:
The DukeEdit software package should include the application (either the PPC or the 68K version), this readme, a registration form, the software licensing agreement, and a tutorial.
Also included is a sample DukeMatch level I created using DukeEdit (JCI2001.MAP). If the package you downloaded was missing any of these items, please contact me and let me know so I can rectify the situation.

DukeEdit is a shareware product, although the unregistered version can be freely used for as long as you like; there is no time limit for evaluation.  The editor as provided is fully functional with one exception:  until registered, DukeEdit will only allow you to save maps containing fewer than 20 sectors.  This should be adequate for evaluation purposes.  If you wish to use this product as a map viewer only, there is no need to register it.  Use it with my blessing.

To register this product, please read the licensing agreement, then fill in and print out the registration form included in this package and send it along with a check for $20 (US currency) to:

John Inman
1042 N. Mountain Ave. #B298
Upland, CA, USA  91786-3631

I currently do not accept any credit cards, although this may change in the future.  Let me know if this is payment option is important to you.
Please note that I require that the payment be made in checks for US dollars only;  any checks sent to me in other monies will be returned uncashed.
Your check will also be returned uncashed if the completed registration form (or facsimile) is not included with your check.
If you do not have access to a printer so that you can print out the registration form, a handwritten copy with the same information will of course be happily accepted.
If you have any questions, feel free to contact me at the above address or e-mail me at jcinman @

Once payment has been received, I will mail or e-mail a registration name and a registration code to you.  You will use these to make your copy of DukeEdit fully functional using the 'Register DukeEdit' menu item in the 'Edit' menu.
The registration name and code work equivalently on either the PPC or the 68K version of DukeEdit, so if you upgrade your system you will not need to obtain a new registration code.

One last and rather obvious point:  please do not post your registration code on the 'net or publish it in any other form.  Keep it safe and secure.  There is nothing quite so discouraging as finding out that the product you worked so long and hard writing and debugging is being given away by those who don't own title to it.  This only causes shareware providers like me to think long and hard before creating another shareware offering. 

I am planning on a number of upgrades to DukeEdit over the coming months, and I have a simple upgrade policy:  upgrades are free for all registered users of DukeEdit.  You will not need to obtain another registration code; the original one I sent you will work for any published version of DukeEdit.  If you experience any problems in this regard, contact the author (me) and I will do whatever it takes to get you up and running.  A list of upgrades I would like to implement can be found at the bottom of this document.  It is a notional list only, and I am not making any promises, but nonetheless there it is.

I have provided a tutorial in this package.  I cannot stress strongly enough that you read through this documentation as you get started with DukeEdit.  It should save you some time.  It also contains examples of things you might try that won't work as you may expect them to.  The fault for these things are entirely mine; there are parts of the user interface that even I don't like and I intend to fix or improve in the future.

I also strongly suggest you obtain some documentation on Duke Nukem mapmaking.  There is some documentation that comes with the game itself, but for better and more complete documentation I recommend either of the following:

1. The Duke Nukem 3D Level Design Handbook, by Matt Tagliaferri, which is available in nearly every decent bookstore.  The only complaint I have about this book is that it has no index, so you have to search around a bit to find what you need. 

2. The Map Editing FAQ 1.3 available online at  In fact, this URL is a great place to find all kinds of information on Duke Nukem, including some great levels, and even some 'Total Conversions' where people have made completely new sounds, artwork and levels.  There is also a forum where you can post mapmaking questions.

There are no doubt other works of equal or better quality, but these two I can vouch for since I have used them myself.

Bear in mind, of course, that these references are meant to be companions to BUILD, the DOS-based program the 3D Realms people used to make their own levels, and will not be tailored to DukeEdit.  You will probably have to do some investigative work on your own to make things work, or if you want, you can drop me a line and I'll try to get back to you.  Be advised that answering technical questions might take a while, since some research may be involved.

Update info:

Version 1.10:
Added ability to launch Duke Nukem from within DukeEdit, using current map.  DukeEdit creates a temporary folder inside the application folder for this purpose.
Added Page Setup and Printing capability.
Added a feature to give the user the option 'print current stratum'.
Added a 'Full Size' dialog so that textures can be viewed full size within the 'Choose Texture' dialog
Added a 'Choose Sound' dialog box for Music&SFX sprites.
Fixed a bug that would permit saving changes made to locked files.
Added code to auto-scroll windows when dragging stuff.
Fixed a preferences bug:  in the case where user selected autosave and skip save warnings,
maps were not saved upon close or quit.  They are properly saved now.
Default x and y repeats are now calculated correctly for things like sides of boxes.
Cleaned up some button titles in the French version.
Made underlying windows redraw when 'Choose Texture' is dismissed after being called from the 'Wall Dialog'.
Fixed a bug that would cause bus errors when the command key is depressed in the choose map dialog.
Fixed sprite code so that cycler sprites automatically have angle set to 270 degrees.  Otherwise they won't work (a 'feature' of Duke Nukem 3D).
Fixed minor rounding error in angle edit box in sprite dialog.

Version 1.02:
Fixed a bug in the create child sector code which could cause spurious failures.
Detect null sectors when map is read.
Patched code to auto-delete null sectors on the fly.
Added an application palette to DukeEdit so colors always come out right.

Version 1.01:
Made all dialogs position themselves at alert position on the main screen.
Made main map windows, when created, size properly so the size box is accessible.
Distributed preferences over three dialogs to help out those with small monitors.
Changed the window titles on the Preferences windows.
Changed the look of the floating windows on System 7.5+ and on OS 8 systems.
Included an OS 8 style folder.
Fixed a bug in the sector creation code that caused problems when creating the ramp in the second tutorial.
Fixed a possible bug in the 'reset' code for the stratum window.

Good Luck,

John Inman, 12/5/97
[email protected]

Upgrades planned, *not* in order of importance, but in a randomly chosen order:

1. Support for third-party group files (i.e. Total Conversions).

2. More texture alignment helpers (graphical presentation of wall textures in relation to neighboring wall textures, for example).

3. Improved palette pop-ups for sprites, walls, sectors.

4. Some sort of help or guide (beyond info window).

5. More tool windows, patterned loosely after the sprite window, that let you drag and drop wall and sector prototypes onto the map (i.e. an existing wall would be changed to match the prototype wall you create in the wall window, similarly for sectors).

6. Save document-specific DukeEdit settings in map file resource fork.

7. Outer loop needn't be first loop in sector -- remove assumption from code.  If this makes no sense to you now, just ignore it.

8. Cut, Copy, Paste ability for sectors, along with requisite dragging and dropping of sectors.

9. Sprite histogram; i.e. a way to determine which sprites appear in a map and with what frequency.

10. Sizing sprites.  Currently the only way to make sprites larger or smaller is by using the xrepeat and yrepeat fields of the sprite window, which is quite non-intuitive.

11.  Implementation of a 'Check Map' feature.

None of these upgrades is guaranteed; I reserve the right to leave them unimplemented if I so desire.  Do not make purchasing decisions for this product (DukeEdit) based on planned upgrades.

The author, John Inman, is a 38 year old American mutt.  He graduated from UCLA with a BS and MS in Mathematics and has worked for 16 years as an engineer at Hughes Aircraft in El Segundo, California.  He lives with his wife and four kids in a nice, quiet neighborhood in Upland, California.  DukeEdit is his first shareware product.

Gaming & Entertainment / SNES PINOUTS & PROTOCOL
« on: February 18, 2017, 04:43:57 pm »
     * Chapter 1) About the Author
     * Chapter 2) Introduction
     * Chapter 3) SNES Multi-out cable connector pins.
     * Chapter 4) SNES Controller cable connector pins.
     * Chapter 5) SNES Controller Communication Protocol
     * Chapter 6) SNES Controller Button-to-Clock Pulse Assignment
   [Document Version: 1.01] [Last Updated: 3/26/96]
                         CHAPTER 1) ABOUT THE AUTHOR
   Author: Jim Christy
   Version: 1.01
   E-Mail: [email protected]
                           CHAPTER 2) INTRODUCTION
   For all you game hardware enthusiasts out there, I took the
   opportunity this weekend to put a scope on my Super Nintendo
   connectors and find out what is going on. Because the standard
   Multi-out cable connector only has internal contacts for the audio and
   video signals, I had to find some more push-in gold contacts at a
   local store to fully break out all the signals. It appears easier to
   do this than make your own connector.
   In short, I found that in addition to S-VHS, the multiout also
   supports RGB and sync. I also got the controller pinouts and protocol,
   which opens up some interesting possibilities. One could rather easily
   construct a "macro recorder" that records your exact button presses
   for a game sequence and allows you to play them back. They will be
   time-accurate by definition of the protocol, and depending on how
   random the game plays, you should be able to replay those sequences
   that get boring, and then take over control when you want.
   If all of this is already well known, then sorry for the waste of net
   These are numbered the way Nintendo did, and the view is looking back
   "into" the connector on the CABLE.

        1       3       5       7       9      11

        |       |       |       |       |       |
        |       |       |   _   |       |       |
       --------------------/ \--------------------
     /                                             \
    |                                               |
    |                                               |
     \                                             /
        |       |       |       |       |       |
        |       |       |       |       |       |

        2       4       6       8      10      12

        Pin     Description
        ===     ===========
        1       Red analog video out   (1v DC offset, 1vpp video into 75 ohms)
        2       Green analog video out (1v DC offset, 1vpp video into 75 ohms)
        3       Composite H/V sync out (1vpp into 75 ohms)
        4       Blue analog video out  (1v DC offset, 1vpp video into 75 ohms)
        5       Ground
        6       Ground
        7       Y (luminance) signal for S-VHS (1vpp into 75 ohms)
        8       C (chroma)    signal for S-VHS (1vpp into 75 ohms)
        9       NTSC composite video signal (1vpp into 75 ohms)
        10      +5v (Could be just a high logic signal)
        11      Left channel audio out
        12      Right channel audio out

   Additional Notes:
   As seen above, the SNES does have RGB capability. I was able to get a
   stable raster on my NEC MultiSync "classic" using the RGB and sync
   pins. However, the video levels are not RS-170 compatible. The DC
   offset needs to be filtered out with some large capacitors and the
   peak-to-peak video amplitude may need to be reduced to 0.7v by using a
   lower load impedance than 75 ohms. The Y/C (S-VHS) signals *appear* to
   be directly usable, but tests cannot be made until I find the pinouts
   for the S-VHS connector on my TV.
   I could not find a Nintendo numbering scheme, so I made one up. The
   view is looking back "into" the connector on the CABLE.

       ----------------------------- ---------------------
      |                             |                      \
      | (1)     (2)     (3)     (4) |   (5)     (6)     (7) |
      |                             |                      /
       ----------------------------- ---------------------

        Pin     Description             Color of wire in cable
        ===     ===========             ======================
        1       +5v                     White
        2       Data clock              Yellow
        3       Data latch              Orange
        4       Serial data             Red
        5       ?                       no wire
        6       ?                       no wire
        7       Ground                  Brown

   Additional notes:
   Pins 5 and 6 show a DC voltage of 5v on a DMM. I forgot to look at
   them on a scope so there may pulses too. However, they don't connect
   to anything at present.
   The controllers have a small circuit board with 2 surface mount 14-pin
   ICs, marked by Nintendo as IC-A and IC-B. Although rubber domes are
   used to provide the tactile response of the buttons, they are not
   capacitive technology as originally thought. Instead they use what
   appears to be carbon impregnated rubber on the underside which makes a
   resistive path (200 ohms) across 2 carbon coated PCB pads when
     * The red wire goes to pin 2 on IC-A.
     * The orange wire goes to pin 8 on both IC-A and IC-B.
     * The yellow wire goes to pin 9 on both IC-A and IC-B.
   IC-A and IC-B appear to be identical, with a 91 date code and have
   another (possible part number) of 545. These are most likely 2
   parallel load shift registers in series. Buttons on the controller
   pull the parallel load inputs to ground through the contact formed by
   pressing a button. IC-B serially feeds IC-A, which then drives the
   serial data line to the SNES CPU.
   Every 16.67ms (or about 60Hz), the SNES CPU sends out a 12us wide,
   positive going data latch pulse on pin 3. This instructs the ICs in
   the controller to latch the state of all buttons internally. Six
   microsenconds after the fall of the data latch pulse, the CPU sends
   out 16 data clock pulses on pin 2. These are 50% duty cycle with 12us
   per full cycle. The controllers serially shift the latched button
   states out pin 4 on every rising edge of the clock, and the CPU
   samples the data on every falling edge.
   Each button on the controller is assigned a specific id which
   corresponds to the clock cycle during which that button's state will
   be reported. The table in section 4.0 lists the ids for all buttons.
   Note that multiple buttons may be depressed at any given moment. Also
   note that a logic "high" on the serial data line means the button is
   NOT depressed.
   At the end of the 16 cycle sequence, the serial data line is driven
   low until the next data latch pulse. The only slight deviation from
   this protocol is apparent in the first clock cycle. Because the clock
   is normally high, the first transition it makes after latch signal is
   a high-to-low transition. Since data for the first button (B in this
   case) will be latched on this transition, it's data must actually be
   driven earlier. The SNES controllers drive data for the first button
   at the falling edge of latch. Data for all other buttons is driven at
   the rising edge of clock. Hopefully the following timing diagram will
   serve to illustrate this. Only 4 of the 16 clock cycles are shown for


                        -->|   |<--

                            ---                               ---
                           |   |                             |   |
        Data Latch      ---     -----------------/ /----------    --------...

        Data Clock      ----------   -   -   -  -/ /----------------   -  ...
                                  | | | | | | | |                   | | | |
                                   -   -   -   -                     -   -
                                   1   2   3   4                     1   2

        Serial Data         ----     ---     ----/ /           ---
                           |    |   |   |   |                 |
        (Buttons B      ---      ---     ---        ----------
        & Select        norm      B      SEL           norm
        pressed).       low                            low
                             -->|   |<--


        Clock Cycle     Button Reported
        ===========     ===============
        1               B
        2               Y
        3               Select
        4               Start
        5               Up on joypad
        6               Down on joypad
        7               Left on joypad
        8               Right on joypad
        9               A
        10              X
        11              L
        12              R
        13              none (always high)
        14              none (always high)
        15              none (always high)
        16              none (always high)

   Additional notes:
   Clock cycles 13-16 are essentially unused. It would be interesting to
   see how the SNES responds if we drive low button data during these
   cycles. Nintendo may use these for future controllers with more
   (From the Editor)
   NOTE: S-VHS is not means to mean Super-VHS. It stands for Super-Video
   (connector and output)
   #### Additional Info (From Kevin Horton)
   OK, the SNES uses the 65816 processor, which is basically a 16-bit
   version of the 6502. It runs at 3.579545 MHz (color-burst), and has an
   8-bit data bus. It can address up to 16MB.
   The carts are nothing more than ROM. To tell you how much data is one,
   take the number of 'MegaBits' and divide by 8 to get megabytes. That's
   how much data is really in the carts. So, an 8-mbit cart really is
   only 1 megabyte.

Pages: [1] 2 3 ... 19